MDX 開發者優先網站 — 無 CMS 鎖定

你的內容不應該被困在別人的資料庫裡

每當你將內容提交到專有 CMS 時，你就在下一個賭注。你在賭廠商不會漲價、不會停用功能、不會被某個根本不在乎你工作流程的公司收購。大多數時候，你會輸掉這個賭注。

MDX 翻轉了這個模式。你的內容以 Markdown 檔案形式存放在你的儲存庫中，並由 JSX 元件增強。它是版本控制的、可攜帶的，並完全由你擁有。沒有在凌晨 2 點過期的 API 金鑰，沒有遷移的噩夢，沒有廠商將你的內容作為人質。

在 Social Animal，我們構建 MDX 驅動的網站，為開發團隊提供對內容架構的完全控制，同時保持編寫體驗的簡潔和快速。

什麼是 MDX，為什麼它很重要？

MDX 是為元件時代設計的 Markdown。它讓你編寫標準 Markdown，並直接在內容檔案中嵌入 React（或任何 JSX 相容的）元件。可以把它看作是開發者工具和內容編寫之間的橋樑。

一個典型的 MDX 檔案看起來像這樣：

# Product Launch Announcement

We're shipping the new dashboard today.

<FeatureGrid features={launchFeatures} />

Read the full changelog [here](/changelog).

<CallToAction variant="primary" />

這是真實的內容配合真實的元件，存放在你的 Git 儲存庫中的 .mdx 檔案裡。無需 CMS 管理面板。無需 REST API 呼叫來渲染標題。

開發者為什麼偏好 MDX

• Git 原生工作流：內容經過與程式碼相同的 PR、審查和部署管道
• 類型安全的元件：你的內容元件在構建時而非運行時進行驗證
• 零運行時成本：MDX 編譯為靜態 HTML — 無需用戶端 Markdown 解析
• 完整的 JSX 能力：互動圖表、嵌入式示範、動態表格 — 全部內聯於你的文章中
• 無廠商依賴：如果你切換框架，你的 .mdx 檔案會隨之移動

廠商鎖定問題是真實存在的

我們已經將客戶從 Contentful、Prismic、Sanity 和 WordPress 遷出過 — 有時在同一季度內全部遷出。模式總是相同的：

1. 一個團隊選擇 CMS，因為它在演示中看起來不錯
2. 他們圍繞專有內容模型構建深度耦合的模板
3. CMS 改變定價、棄用 API 版本，或引入破壞性變更
4. 遷移成為多個衝刺的項目，阻止了功能工作

使用 MDX，遷移不是問題。你的內容是檔案。檔案存放在資料夾中。資料夾存放在 Git 中。從 Next.js 移動到 Astro？你的 MDX 檔案不會在乎 — 它們在兩者中都能工作。

"無廠商鎖定"實際上是什麼意思

它不是說我們反對 CMS。它是說你的內容層沒有你無法控制的單點故障。具體來說：

• 無專有內容模型 — 你的架構在程式碼中定義，不在廠商的儀表板中
• 構建時無 API 依賴 — 內容是本地的，構建是快速且確定性的
• 無每座定價驚喜 — 沒有 SaaS 帳單附加到你的內容
• 無遷移稅 — 切換框架或主機不需要重新平台化內容

我們對 MDX 優先架構的方法

我們不只是將 MDX 檔案放入 /content 資料夾然後就完事了。我們構建可擴展的適當內容架構。

使用 Frontmatter 驗證的內容架構

每個 MDX 檔案都使用 Zod 或類似的運行時驗證器獲得驗證的 frontmatter 架構。你的內容具有強制結構 — 必填欄位、類型化日期、驗證的 slug — 無需 CMS 來強制執行。

const postSchema = z.object({
  title: z.string().max(70),
  date: z.coerce.date(),
  tags: z.array(z.string()),
  draft: z.boolean().default(false),
});

推送一個格式不正確的內容檔案，構建將失敗並顯示清晰的錯誤。這比大多數 CMS 平台提供的驗證更好。

自訂元件庫

我們構建針對你的內容需求量身定制的可重用 MDX 元件集。常見範例：

• <Callout> — 樣式化的提示、警告和資訊區塊
• <CodeDemo> — 具有語法突出顯示的即時程式碼範例
• <ComparisonTable> — 結構化的功能比較
• <VideoEmbed> — 響應式、延遲加載的視訊，具有正確的寬高比
• <PricingCard> — 從你的資料層提取的動態定價元件

這些元件已編檔、經過測試，並與你的內容一起版本控制。

內容集合和類型安全

使用 Astro 的 Content Collections 或 Next.js 配合自訂加載器，我們建立完全類型化的內容 API。你的 IDE 自動完成內容欄位。TypeScript 在部署前捕獲損壞的引用。老實說，DX 勝過我使用過的任何 CMS GraphQL 探索器。

非開發者編寫選項

MDX 不意味著每個人都需要在 VS Code 中工作。我們在需要時添加輕量級編輯層：

• Prose Mirror 或 TinaCMS 用於使用 Git 支持儲存的視覺編輯
• Decap CMS（前身為 Netlify CMS） 用於簡單的管理 UI，提交到你的儲存庫
• GitHub 的內置編輯器 具有預覽工作流以進行快速修復
• 自訂管理儀表板 使用伺服器操作以程式設計方式提交 MDX 檔案

內容保留在 Git 中。編輯體驗適應做編寫的任何人。

技術堆棧

我們的 MDX 構建通常在以下環境上運行：

• Next.js 14+ 配合 next-mdx-remote 或 @next/mdx 用於 App Router 整合
• Astro 配合原生 MDX 支持和 Content Collections 用於靜態優先網站
• Rehype 和 Remark 外掛程式 用於語法突出顯示、目錄生成、連結處理和影像優化
• Tailwind CSS 用於使用設計令牌的元件樣式設定
• Vercel 或 Netlify 用於部署，具有即時回滾（你的內容在 Git 中，所以每個部署都是可逆的）

你會得到什麼

當我們提交 MDX 優先網站時，你會獲得：

• 一個完全部署的網站，頁面加載時間不到一秒
• 一個具有驗證的文檔化內容架構
• 一個自訂 MDX 元件庫
• 一個基於 Git 的內容工作流，具有預覽部署
• 零月度 CMS 成本
• 對每個內容檔案、元件和配置的完全所有權
• 一個不存在的遷移路徑 — 因為沒有什麼可遷移離開的

這是為誰提供的

MDX 優先架構非常適合：

• 開發者工具公司 想在一個堆棧中建立文檔、部落格和行銷頁面
• 初創公司 不想在有收入前為 CMS 支付 $300/月
• 代理商 厭倦了在數十個客戶網站上維護 CMS 整合
• 工程團隊 想在他們的單一儲存庫中放置內容，而不是第三方儀表板

如果你的團隊習慣於 Git，並且你重視長期所有權而不是短期便利，MDX 就是正確的選擇。