為什麼我需要 MDX？從靜態文檔到互動應用
這篇文章本身就是由 MDX 渲染的。
我們常問：「如果 Markdown 已經能做很多事，為什麼還要引入 MDX？」
答案在於：Markdown 是為了「閱讀」，MDX 是為了「互動」。
以下我將直接在這個頁面上展示它們的區別。
1. 靜態 vs 動態
普通 Markdown（靜態）
普通的 Markdown 很適合展示程式碼、列表和文字。它是死的，讀者只能看。
// 這只是一段靜態程式碼
const greet = "Hello World";
console.log(greet);
MDX（動態）
但在 MDX 裡，我可以嵌入一個 活生生的 React 組件。試試看點擊下面的按鈕：
這是 React 組件：計數器
👆 剛剛發生了什麼？
這不是 GIF，也不是嵌入的 iframe。這是直接在這個頁面運行的 React 程式碼（State）。普通的 .md 檔案永遠做不到這一點。
2. 傳遞參數（Props）
MDX 最強大的地方在於我們可以像寫 HTML 一樣傳遞資料給組件。這讓維護重複性的 UI 變得非常簡單。
例如，我定義了一個 <Callout /> 組件，我可以隨意改變它的標題和樣式：
💡核心觀念
MDX 把文章視為 資料（Data），但也把文章視為 組件樹（Component Tree）。
⚠️警告：複雜度提醒
雖然功能強大，但請記得：如果不需要互動，盡量使用普通 Markdown，以保持構建速度輕量化。
✅小技巧
你可以在 MDX 中混用 Markdown 語法和 React 組件，兩者完美共存。
3. 資料驅動的內容
假設我正在寫一份團隊介紹文件。在普通 Markdown 裡，我得手寫 HTML 表格。但在 MDX 裡，我可以複用組件：
這意味著你的 設計系統（Design System） 可以直接在你的部落格文章中生效。
4. 動態計算
MDX 還能執行 JavaScript 邏輯。例如，顯示距離某個日期還有多少天：
距離 2030 年：1489 天這個數字是即時計算的，每次你重新載入頁面都會更新。這在普通 Markdown 中是完全不可能的。
什麼時候該用 MDX？
讓我們回到最初的決策點：
| 需求 | 建議 |
|---|---|
| 純文字 + 圖片 + 程式碼 | ✅ 用 .md |
| Mermaid 流程圖 | ✅ 用 .md + remark 插件 |
| Chart.js / ECharts | ✅ 用 .md + 全局腳本 |
| 嵌入互動組件 | 🔥 用 .mdx |
| 傳遞 Props 給組件 | 🔥 用 .mdx |
| 動態計算內容 | 🔥 用 .mdx |
比喻總結
「用 Markdown 時，你在寫文章；用 MDX 時，你在寫應用。」
- Markdown 是「印刷書」——資訊靜態、一次寫好
- MDX 是「互動電子書」——讀者可以操作、體驗
如果你只是想「展示」——那就安心回到 Markdown，它更輕、更快、更單純。
只有當你真的需要「讓文章的一部分動起來、連 API、接狀態」，才打開 MDX 這扇門。
結語
這篇文章本身就是最好的證明：
- ✅ 你看到了互動計數器
- ✅ 你看到了可配置的提示框
- ✅ 你看到了資料驅動的用戶卡片
- ✅ 你看到了動態計算的日期
這些都是 只有 MDX 才能做到 的事情。
但請記住：能力越大，責任越大。不要為了炫技而使用 MDX——只在真正需要互動的時候才使用它。