Mermaid 文字畫圖 — 用純文字產生流程圖與架構圖

由 FeiYueh 親自審稿驗證 · 最後更新於 2026-09-28

Mermaid 讓流程圖變成可版本控管的純文字：一段 10 行的程式碼區塊就能產出完整流程圖，改圖只需改字、不必重畫。GitHub、GitLab、Notion、Obsidian 都已內建原生渲染，這代表你寫在 README 或筆記裡的圖表不需要任何外掛就會自動顯示。為什麼文字畫圖比拖曳工具更適合放進文件圖表與文件不同步，是技術文件最常見的腐化來源。用 Figma 或 draw.io 畫的架構圖存成 PNG 後，程式碼改了、圖沒改，半年後圖比註解還誤導人。Mermaid 把圖的定義寫進同一份 Markdown，改動出現在 diff 裡、進得了 code review，圖表因此和程式碼一起演化。採用規模已足以構成事實標準。「GitHub 於 2022 年 2 月在所有 Markdown 檔案中內建 Mermaid 渲染支援」（來源：GitHub Blog），這一步讓數千萬個 repository 的 README 立刻具備畫圖能力。「mermaid 套件 npm 週下載量超過 200 萬次」（來源：npm 官方套件頁），顯示它已深入前端與文件工具鏈。「mermaid-js/mermaid 專案在 GitHub 累積超過 78,000 顆星」（來源：GitHub 官方 repository），在文件類開源專案中屬於前段班。實務上的差異可以量化：畫一張含 8 個節點、3 條分支的流程圖，用滑鼠拖曳工具通常要 10 到 15 分鐘處理節點對齊與連線走向；用 Mermaid 寫 12 行文字約 2 分鐘，且排版由佈局引擎自動計算，不會有「線交叉得很醜」需要手工搬移的問題。四種最常用的圖型與最小可用語法流程圖：flowchart flowchart 是使用頻率最高的圖型，語法核心只有「節點」和「箭頭」兩件事。方向用 TD （由上而下）或 LR （由左而右）宣告： flowchart TD A[使用者送出表單] --> B{欄位驗證} B -->|通過| C[寫入資料庫] B -->|失敗| D[回傳錯誤訊息] C --> E[寄送確認信] D --> A 括號形狀決定節點外觀： [方框] 是流程步驟、 {菱形} 是判斷、 ([圓角]) 是起訖點、 [(圓柱)] 是資料庫。箭頭上的 |文字| 是分支標籤。掌握這五種形狀，九成的業務流程圖都畫得出來。時序圖：sequenceDiagram 時序圖用來描述多個角色之間的訊息往返順序，是說明 API 呼叫鏈與認證流程的標準工具： sequenceDiagram participant 使用者 participant 前端 participant 金流商使用者->>前端: 點擊結帳前端->>金流商: 建立交易單金流商-->>前端: 回傳付款網址前端->>使用者: 導向付款頁金流商->>前端: 付款結果 webhook ->> 是實線箭頭（發出請求）， -->> 是虛線箭頭（回傳回應）。這個實線／虛線的區分讓讀者一眼看出誰主動、誰被動，比在流程圖裡硬塞順序編號清楚得多。甘特圖：gantt gantt 適合把專案排程直接寫進 README，避免另開一份會過期的試算表： gantt title 上線前置作業 dateFormat YYYY-MM-DD section 開發後端 API :a1, 2026-09-01, 14d 前端串接 :after a1, 10d section 驗證整合測試 :2026-09-25, 7d after a1 這種相對依賴寫法是文字格式的優勢：前置任務延後三天，後續任務會自動順延，不需要像試算表那樣逐格重拉日期。實體關聯圖：erDiagram erDiagram 用來畫資料表關係，適合放在資料庫設計文件開頭當導覽： erDiagram USERS ||--o{ ORDERS : places ORDERS ||--|{ ORDER_ITEMS : contains PRODUCTS ||--o{ ORDER_ITEMS : "appears in" 關係符號讀法是把 | 當「恰好一個」、 o 當「零個」、 { 當「多個」。 ||--o{ 就是一對多且右側可為零。完整符號表見 Mermaid 官方 ER 圖語法文件。在哪裡寫、在哪裡看得到渲染環境分成三類，選錯會出現「本機看得到、線上一片空白」的落差。原生支援平台：GitHub、GitLab、Notion、Obsidian、Azure DevOps。在 Markdown 中用 ```mermaid 圍住程式碼即可，不需安裝任何東西。線上編輯器： Mermai

Mermaid 文字畫圖 — 用純文字產生流程圖與架構圖

相關工具書