TechMoon 科技月球
WordPress、SEO 與 AI 工具實測指南
開源等寬字型 JetBrains Maple Mono，把中文字縫進編輯器
JetBrains Maple Mono 用十五行 FontForge 腳本把 Maple Mono 的中日字元縫進 JetBrains Mono，實測中英字寬精確 2:1（0.600 對 1.200 em），而官方 JetBrains Mono 字型檔裡確實找不到任何中日字元。穩定版停在 2025 年 12 月反映的是上游發版節奏而非棄坑，OFL-1.1 授權免費商用，代價是 134MB 起的下載包與 Visual Studio 的理想渲染設定。
用 AI 摘要這篇文章：
把字型檔實際打開來量：JetBrains Maple Mono 的英數字，每個字元寬 0.600 em；中文字，每個字元寬 1.200 em。剛好兩倍，量了十幾個字元，一分不差。這個數字就是這款字型存在的理由：你在程式碼編輯器裡打中文註解、中文字串，它會跟英數字對齊在同一套格線上，不會歪。
先用一段白話把這件事講清楚。等寬字型的意思是每個字元佔一樣寬的格子，i 跟 w 一樣寬，這是程式碼能對齊的基礎；中英 2:1 的意思是中文字剛好佔兩個英數字的格子。有這個規格，游標移動、縮排對齊、視覺欄位計算才會在混排時繼續成立。反過來說，只要備用字型的中文寬度帶一點不確定，整個格線就散了，這也是為什麼「等寬」是開發者字型的底線要求，而「中日字元也等寬」是更少字型做到的事。
JetBrains Maple Mono 是一個第三方開源字型，做法是把 JetBrains Mono 與 Maple Mono 兩個現有字型縫合：拉丁字母與符號全部使用 JetBrains Mono 的字形，中日字元全部使用 Maple Mono 的字形。顧名思義它跟 JetBrains 公司沒有官方關係，維護者是一位獨立開發者，專案在 2025 年 2 月建立，目前累積 2,280 顆星，採 OFL-1.1 授權，個人使用與商業嵌入都免費。它特別的地方在於維護方式：整個字型由 GitHub Actions 自動重建，上游兩個字型任何變動，縫合版會自己跟著更新，理論上永遠不會過時。
這款字型的細節值得攤開來看，因為它的可核對程度比一般字型專案高得多：字型檔抓下來就能量、縫合腳本與自動化流程的原始碼全部公開，版本與更新紀錄也查得到。接下來的每個數字，都是從這些地方直接讀出來的。
JetBrains Mono 官方字型檔裡，一個中文字都沒有
許多開發者的編輯器預設字型就是 JetBrains Mono，但它有個很少被明講的事實：官方字型檔裡完全沒有中日字元。把官方 repo 的 Regular 版抓下來數，字元表一共 1,372 個字元，涵蓋拉丁、西里爾、希臘三個系統，寬度全部統一；但拿「中」這個字去查，不存在，日文假名「あ」也一樣不存在。
後果每個人都遇過，只是很少人想過原因：編輯器遇到字型裡沒有的字元，會把顯示工作丟給系統指定的備用字型。備用字型的字寬、字重、造型都跟原字型對不上，於是你的英文程式碼整整齊齊，中文註解一碰到就寬窄不一、視覺上斷成一截一截。更細的困擾在游標與選取：格線混亂之後，游標跳動的距離不再跟視覺對應，選取一段中文時亮起來的區塊跟你想的不完全一樣。這就是縫合字型的切入點：補上缺的字元，而且用同樣 2:1 的寬度規格補。
分工在專案的致謝名單裡寫得很清楚：所有非中日字形來自 JetBrains Mono，所有中日字形來自 Maple Mono，而 Maple Mono 的中日基礎又來自 Resource Han Rounded 與思源黑體。實際從 CDN 抓下來的縫合字型分塊驗證，繁體中文常用字都在，「台、灣、體、編、碼」每個字寬都是 1.200 em，跟英數字的 0.600 em 精確成兩倍。這是量出來的，官方展示圖裡那些對齊效果，背後就是這組數字。
十五行腳本縫出來的字型
縫合本身有多複雜？整個核心是一支 258 bytes 的 FontForge 腳本，扣掉註解與換行，有效內容十五行：開啟 JetBrains Mono、用 MergeFonts 把 Maple Mono 的中日版併進來、設好名稱資訊，然後跑一輪自動處理，包含自動 hint、加上極值控制點、輪廓整理、座標取整、移除重疊路徑。就這樣。縫合的門道不在技術難度，在於誰願意把這件事的自動化做到底。
圍繞這十五行的是 432 行的自動化流程。每次執行會先把兩個上游字型從原始碼完整建置一次，再以十六種字重（Thin 到 ExtraBold，含斜體）乘上各種變體組合逐一縫合，最後做後設資料手術：用 ttx 把平均字寬硬寫成 600、補上中日文字碼頁標記，並把三份版權聲明（JetBrains Mono 專案、Maple Mono 專案、縫合作者）一起寫進字型的名稱表。最後一項我實際驗過：抓下來的 CDN 字型，CSS 檔頭確實帶著三行完整版權，授權鏈是乾淨的。
流程裡還有幾個設計值得點出來。發現上游沒變動時，重活整段跳過，只更新看門狗時間戳，所以絕大多數執行是輕量的；也有手動觸發的開關，可以在 GitHub 頁面勾選強制重新縫合，不等上游。產物分兩條線發布：上游正式 release 變動時發穩定版並標為 latest，上游 commit 變動時發 pre 版並標為 preview，兩條線互不覆蓋。這套「偵測、建置、縫合、後設資料、發布」全部無人值守的結構，就是它敢說自己不會過時的底氣。
順帶解釋一下變體表裡的 HT，它背後是字型工程的取捨。Hinting 是在字型裡預先寫進「像素級微調指令」，讓字元在低解析度螢幕上的線條落點更均勻；代價是高解析度螢幕上，這些指令反而讓曲線邊緣多了一點不自然的感覺。所以同一個組合會同時提供 HT 版與無 hinting 的 XX 版，讓你照自己的螢幕挑，這個取捨在檔名層級就分好了。
連字（ligatures）也是同一條產線處理。你看到 => 自動變成箭頭、!= 變成帶斜線的等號，這些是字型內建的連字替換。不想要連字的人，抓 NL 版，它由另一支小腳本把連字設定整組移除，其餘完全不動。
穩定版停在 2025 年 12 月，瓶頸在上游
打開下載頁，最上面的穩定版是 1.2304.79，發布日期 2025 年 12 月 5 日，到今天九個月沒有新版。第一眼像棄坑，其實版號本身就藏著解釋：規則是 1.JetBrains 版號.Maple 版號，2304 對應 JetBrains Mono 2.304，79 對應 Maple Mono 7.9。往前翻每一版都符合這個規則。
對帳上游就會發現，穩定版凍結的原因完全在外面。JetBrains Mono 這個上游，最後一次正式發版是 2023 年 1 月 14 日的 2.304，到現在超過三年半沒有新 release；Maple Mono 的最後一次發版是 2025 年 12 月 5 日的 7.9，跟縫合版的穩定版同一天。換句話說，縫合版的穩定版只在「上游有新 release」時才重建，它已經把自己能做的都做完了，是在等上游。
那 repo 天天都有活動紀錄，原因在哪？那是看門狗：自動化流程每輪都會把 README 裡的「最近一次檢查更新時間」更新一次，看起來像天天在開發，實際上多數 push 只是時間戳。真正的字型更新走另一條通道：上游的 commit 層級變動會發到 pre 版（GitHub 上標為 preview），最近一次是 2026 年 9 月 16 日，融合了兩個上游的最新 commit。想要最新字形的人抓 pre，要穩定就抓 latest；一般人抓 latest 就好，字型的「新鮮度」對使用體感影響很小，pre 版的價值主要在於證明這條自動線還活著。
這裡有個 README 說法與實測的落差值得知道。README 寫每 5 到 30 分鐘檢查一次上游更新，流程設定檔裡的排程也真的是每 5 分鐘跑一輪；但我拉了最近三十次實際執行紀錄，間距最短 106 分鐘、最長 331 分鐘、中位數 218 分鐘，GitHub 對高頻排程有節流，實際節奏是每兩到五小時檢查一次。對字型這種更新頻率的東西，小時級已經夠用，只是別照著 README 想像它分鐘級在盯。
下載哪一個：讀懂檔名後四碼
Release 頁面的檔名格式固定：JetBrainsMapleMono-後面接四組代碼，每組要嘛是特定代碼、要嘛是 XX（代表不加這個特性）。全部組合如下。
| 代碼 | 意思 | 選或不選的考量 |
|---|---|---|
| NF | Nerd Font，終端機與開發工具的圖示字元 | 常用終端機、想讓 git 狀態圖示正常顯示就上；檔案會變大 |
| NR | 縮小中日字元間距 | 會放棄中英 2:1 對齊；要對齊就別選 |
| NL | 移除連字 | 不喜歡 => 變箭頭的人選這個 |
| HT | 附 hinting，低解析度螢幕渲染較均勻 | 螢幕解析度較低選 HT，高解析度螢幕選 XX 版反而更銳利 |
不確定的話，README 的建議是直接抓四個都是 XX 的基本版：JetBrainsMapleMono-XX-XX-XX-XX.zip。舉一個完整例子走一遍：JetBrainsMapleMono-NF-XX-XX-HT.zip，意思是要 Nerd Font 圖示、維持標準中日間距、保留連字、附 hinting；換成在 4K 螢幕上用、不碰終端機的人，對應的選擇就會是 XX-XX-XX-XX。實測檔案大小，不含 NF 的 zip 約 134 MB，含 NF 約 152 MB，因為每個包都裝了全部十六種字重。只想在網頁裡用它的人不用抓 zip：官方 README 提供的第三方 CDN（ZSFT 字型庫）有 web 字型版，Regular 一種字重就切了 183 個 woff2 分塊，CSS 引用即可，網頁只會下載用到的字元分塊，我們先前實測過這個字型庫的分塊與授權設計。
裝進編輯器前，先改兩個設定
Visual Studio 用戶有一個必改項：設定、文字編輯器、進階裡面的「文字格式設定方法」，要改成「理想」，README 的注意事項特別提醒沒改的話渲染會不均勻。這個提醒有實際案例：2026 年 7 月還有人開 issue 反映找不到這個設定在哪，可見踩到的人不少。VS Code 這邊則是要開連字的人在 settings.json 加上 "editor.fontLigatures": true，不要連字就不用動。
安裝管道也要先知道：沒有 brew、沒有 scoop。這兩個需求在 2025 年 3 月就有人分別開 issue 許願，到今天都沒有實作，所以 macOS 與 Windows 都是一樣的流程：下載 zip、解壓縮、把 .ttf 字型檔裝進系統（macOS 用字型簿打開後按安裝，Windows 在檔案上按右鍵選安裝），再到編輯器把字型指向 JetBrains Maple Mono。十六種字重一次全裝也不衝突，編輯器裡通常只會用到 Regular、Bold 加斜體這幾個，其餘的留著給終端機或主題挑。
不換、換 Maple Mono 原版、改用縫合版
三條路線的取捨其實很清楚。留在 JetBrains Mono 原版，中文會繼續掉到備用字型，對齊問題原封不動，這是量測已經證實的現狀。換去 Maple Mono 原版（上游有 28,954 顆星，規模是縫合版的十幾倍），它本身就自帶中日字元與同樣的 2:1 規格，不用縫；差別只剩下你要哪一家的拉丁字形：JetBrains Mono 的俐落直切，或 Maple Mono 的圓角。縫合版的存在理由，就是給「認定了 JetBrains Mono 手感、只缺中文」的那群人。
還有一個實務場景值得放進考量：終端機。命令列提示符、git 狀態、檔案樹這些輸出大量依賴圖示字元，這正是 NF 版的用武之地，配上支援的 shell 主題，提示符號不會再顯示成問號或豆腐框。編輯器與終端機用同一個字型，視覺上的一致感比多數人想像的有感，這也是為什麼打包十六字重雖然笨重，對重度使用者反而省事。
換句話說，判斷順序是先看自己打不打中文。純英文環境，直接用原版就好，縫合版對你沒有增量。天天在程式碼裡寫中文註解、中文 commit 訊息，又想留住 JetBrains Mono 的字形，縫合版是現成解法，而且裝完就是成效：中文註解落在格線上，截圖給同事看也整齊。字形手感與長期閱讀的舒適度是另一回事，量測給不了答案，裝了用幾天自己定奪，這也是所有字型共同的挑選方式。
先把代價攤開：單人維護、整包下載、無套件管理器
- 單人維護的第三方專案：全部自動化降低了維護負擔，但上游若改授權、改結構，縫合流程需要人來調整，風險集中在一位維護者身上。
- 沒有單字重下載：每個 zip 都是十六種字重全包，134 MB 起跳，只想試一種字重的人也要抓整包。
- 沒有可變字重版本：需求在 2025 年 6 月就有人提出，官方路線圖有列，目前仍未提供。
- 官方 release 不出 woff2：web 字型需求同樣有人開 issue，目前的解法是第三方 CDN，等於把 web 版的供應鏈寄放在別人家。
- Visual Studio 的「理想」設定沒改，會誤以為字型有問題。
- 完整建置一次約三小時是 README 的自述，我沒有重跑驗證；對使用者的影響是理解它為什麼非自動化不可。
授權乾淨，判斷只剩一個問題：你打不打中文
授權是這個專案最無聊也最讓人放心的部分。OFL-1.1 條文：字型可以免費使用、修改、再散布，可以跟著任何軟體捆綁出售，唯二限制是字型檔本身不能單獨賣、衍生字型必須維持同樣授權。對一般開發者與公司來說就是一句話：裝了用，不用問任何人。想在專案裡找更多這類資源，可以翻我們先前的免費可商用字體整理與 Velvetyne 開源字型庫介紹。
最後給個可以直接驗收的判斷。你的編輯器現在打一行 width *= 2; // 寬度加倍，中英文如果對不齊、粗細不一致，裝這個字型後同一行應該落在同一套格線上，這就是成功。裝完沒有改善，先檢查 Visual Studio 的渲染設定；真的不喜歡它的字形手感，退一步用 Maple Mono 原版，對齊規格是一樣的。至於版本焦慮可以放下了：它會自己等上游、自己更新，你要做的只是偶爾看看下載頁有沒有新號碼。對這類工具想保持追蹤的人，把 release 頁的 watch 打開即可，有新穩定版 GitHub 會通知你，不需要盯著 repo 的每日活動看，那些活動絕大多數只是時間戳在走路。
