前端開發 | Peter.H 的技術筆記

解決 CKEditor 圖片水平排版在前端顯示為垂直排列的問題

前言：編輯器與前端的排版不一致之謎在開發多平台醫療健康應用時，我們採用了現代化的技術棧：後端 CMS：Strapi v5.15.1（Headless CMS）前端框架：Vue.js 3 富文本編輯器：CKEditor 5 資料傳輸：GraphQL API 這個組合在大多數情況下運作良好，編輯者可以在 Strapi 後台使用 CKEditor 輕鬆編輯富文本內容，前端 Vue.js 應用透過 GraphQL 獲取並渲染這些內容。然而，我們遇到了一個令人困惑的問題：在 Strapi 後台使用 CKEditor 精心排版的水平並排圖片，到了前端網頁卻變成了垂直排列。這個問題不僅影響了內容的視覺呈現，也破壞了編輯者的排版意圖。更重要的是，這讓非技術背景的內容編輯者感到困惑：「為什麼我在後台看到的排版，到了網站上就變了？」這篇文章將深入探討這個問題的根本原因，並提供系統性的解決方案。問題現象與環境說明內容流程架構我們的內容從編輯到展示的完整流程如下： sequenceDiagram participant Editor as 內容編輯者 participant Strapi as Strapi 後台 participant CKEditor as CKEditor 5 participant DB as 資料庫 participant GraphQL as GraphQL API participant Vue as Vue.js 前端 participant Browser as 使用者瀏覽器 Editor->>Strapi: 登入後台編輯內容 Strapi->>CKEditor: 載入富文本編輯器 Editor->>CKEditor: 編輯內容，設定圖片水平排列 CKEditor->>CKEditor: 生成 HTML（含 float 樣式） CKEditor->>Strapi: 儲存富文本內容 Strapi->>DB: 儲存到資料庫 Note over Editor,DB: 編輯階段完成 Vue->>GraphQL: 請求內容資料 GraphQL->>DB: 查詢內容 DB-->>GraphQL: 回傳富文本 HTML GraphQL-->>Vue: 回傳 JSON（含 HTML 字串） Vue->>Vue: 使用 v-html 渲染 HTML Vue->>Browser: 顯示最終頁面 Note over Browser: ❌ 問題：圖片垂直排列<br/>（預期：水平排列）問題的具體表現預期行為： ...

Vue.js SPA 社交分享完整指南：解決 Facebook/LINE OpenGraph 爬蟲問題

引言：當精美的網站變成分享時的「無名氏」在現代 Web 開發中，社交媒體分享功能是不可或缺的一部分。當用戶在 Facebook、LINE 或其他社交平台分享你的網站連結時，你希望顯示的是精美的預覽卡片，而不是空白或錯誤的資訊。然而，對於使用 Vue.js、React、Angular 等前端框架開發的單頁應用程式（SPA），這個看似簡單的需求卻隱藏著技術挑戰。本文將完整記錄從問題發現、原因分析、到解決方案實作的全過程。問題發現：為什麼分享連結總是顯示預設值？場景描述我的平台 www.abc.com 是一個基於 Vue.js 3 + Strapi CMS 的網站。某天，我發現一個嚴重問題：當用戶分享服務頁面（如 https://www.abc.com/service-us/6）到 Facebook 或 LINE 時，顯示的預覽資訊總是預設值，而非該服務的實際標題和描述。實際情況對比：情境期望結果實際結果分享服務頁面顯示「專業網站開發服務」顯示「ABCDEFG（預設標題）」分享部落格文章顯示文章標題與摘要顯示網站預設描述分享產品頁面顯示產品圖片與名稱顯示網站 Logo 診斷工具測試使用 Facebook Open Graph Debugger 測試後發現：爬蟲抓取到的 HTML： <!DOCTYPE html> <html lang="zh-TW"> <head> <meta charset="UTF-8"> <title>ABCDEFG</title> <meta property="og:title" content="ABCDEFG"> <meta property="og:description" content="預設網站描述">  </head> <body> <div id="app"></div> <script src="/assets/index.js"></script> </body> </html> ⚠️ 關鍵發現：爬蟲只看到靜態的 HTML 模板，完全沒有 JavaScript 執行後動態生成的 meta 標籤。 ...

前端登入失敗的真兇：深入理解 CORS 問題與實戰解法

前言：那個令人抓狂的錯誤訊息在開發前後端分離的 Web 應用時，幾乎每位工程師都曾遇過這個令人頭痛的錯誤： Access to fetch at 'http://localhost:1337/api/auth/local' from origin 'http://localhost:5173' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. 這個錯誤通常發生在最關鍵的時刻：前端登入功能即將完成，卻無法呼叫後端 API 串接第三方服務時，資料無法正常取得部署到測試環境後，原本運作正常的功能突然失效 CORS（Cross-Origin Resource Sharing，跨來源資源共用）是現代 Web 開發中的核心安全機制，但也是許多開發者的痛點。這篇文章將從基礎原理到實戰應用，帶你完整理解 CORS 的運作方式，並提供實際可用的解決方案。為什麼需要 CORS？從同源政策說起同源政策的誕生在理解 CORS 之前，我們需要先認識「同源政策」（Same-Origin Policy, SOP）。這是瀏覽器最基本的安全機制，在 1995 年 Netscape Navigator 2.0 引入 JavaScript 時就已經存在。同源政策的目的：防止惡意網站讀取另一個網站的敏感資料。想像一個情境：你登入了網路銀行（https://bank.com），此時你的瀏覽器保存了銀行的登入 Cookie。如果沒有同源政策，當你不小心訪問了一個惡意網站（https://evil.com），該網站的 JavaScript 就能透過你的瀏覽器向 https://bank.com 發送請求，並讀取你的帳戶資料。同源政策阻止了這種攻擊：https://evil.com 的 JavaScript 無法讀取 https://bank.com 的回應內容。什麼是「同源」？兩個 URL 被視為同源，必須滿足以下三個條件： ...