軟體編輯器原理：為什麼語法高亮
二、為什麼需要語法高亮：認知與人因工程的角度
2.1 降低視覺搜尋成本
閱讀程式碼和閱讀自然語言有一個關鍵差異：自然語言的冗餘度極高。一段中文裡即使有幾個字看不清，你仍能靠上下文補全語意。但程式碼的冗餘度極低——if (a = b) 和 if (a == b) 只差一個字元，語意卻天差地遠。這種「低冗餘、高精確」的特性，意味著閱讀程式碼時，眼睛必須頻繁進行局部掃描：這個變數在哪裡定義？那個括號對應到哪裡？這行是不是被註解掉了？
顏色在這裡扮演的角色，是把「需要仔細辨識」的工作轉換成「可以快速分類」的工作。當註解是灰色、字串是綠色、關鍵字是藍色時，你的眼睛不需要真正讀完每一個字，就能靠顏色塊快速跳過一大段註解，或迅速定位到下一個函式定義。這是一種典型的「以視覺特徵換取認知資源」的策略：把辨識負擔丟給比較低階的視覺系統，把省下來的工作記憶留給真正的邏輯推理。
2.2 前注意處理：顏色是「不用看就看見」的
認知心理學有個概念叫前注意處理（pre-attentive processing）：某些視覺特徵（顏色、大小、形狀、運動）能在數十到數百毫秒內，在整個視野中被平行處理，不需要逐項掃視。換句話說，當你打開一個檔案，還沒「讀」任何一行，你的大腦其實已經隱約感知到「這裡有一塊綠色的東西」、「那邊有一大段灰色」。這種全域的、先於意識的感知，會直接影響你第一眼要把注意力放在哪裡。
這也解釋了為什麼語法高亮的顏色對比度比「正確性」有時更影響體驗。假設某個編輯器的解析器非常精準，卻把註解設成和識別字幾乎相同的深灰色，那麼它前注意處理的效果會被嚴重削弱——你無法一眼看出「這一段是死的」。反之，一個用簡單正規表達式實作、偶爾誤判的高亮器，只要色彩層級分明，實用價值往往更高。這是軟體評測時很容易忽略的維度：高亮的價值不只在「分對類」，更在「分得開」。
2.3 錯誤偵測與結構感知
顏色還有一個副產品：它讓語法錯誤「浮出來」。當你打到一半，發現整段程式的顏色突然全部變成字串色，你立刻知道少了一個引號；當某個本該是關鍵字的字顯示為普通識別字，你可能拼錯了 whlie。這種「以顏色異常作為錯誤訊號」的機制，比等到編譯器報錯快得多，也便宜得多。
更進一步，成熟的編輯器會把結構感知視覺化：縮排參考線、括號配對高亮、摺疊區塊的箭頭、當前行所屬的函式名稱。這些嚴格來說不算「語法高亮」，但共享同一套分析管線，也服務同一個目的——讓程式的樹狀結構變得可見。人類短期記憶容量有限，很難同時記住五層縮排的巢狀關係；把它們畫出來，等於把一部分認知負擔外包給視覺。
2.4 情境切換與疲勞管理
還有一個常被低估的功能：情境切換的視覺提示。當你在同一個專案裡開著十幾個分頁，Frontend 的 TypeScript、後端的 Go、設定檔的 YAML、CI 的 shell script，各自的語法規則不同。如果全部都是同一種顏色，你在切換分頁時需要重新建立上下文；但如果 YAML 的鍵是藍色、值大多是綠色，Go 的函式名是黃色，你的大腦會靠顏色快速辨認「我現在在哪一種檔案裡」。這是一種低成本的模式切換輔助，對每天在四五種語言之間跳來跳去的人特別有感。
此外，長時間閱讀程式碼的眼睛疲勞，很大一部分來自「對比不足」與「色彩過載」兩個極端。好的高亮主題會在兩者之間取得平衡：背景與前景有足夠對比，但不同語法類別之間的顏色差異被控制在少數幾個色相上，避免視覺系統不斷重新適應。這部分我們在後面第六章會詳細談。
三、語法高亮的實作原理：從字串到顏色的管線
3.1 詞法分析：把字元流切成 Token
一切從詞法分析（lexing / tokenization）開始。給定一個檔案的字元流，詞法分析器的目標是把它切成一個個 token，每個 token 帶有三樣資訊：型別（keyword、identifier、string、comment、number……）、起始與結束位置、以及必要時的內容。
最直觀的作法是「有限狀態機」：從左到右掃描，維護一個當前狀態。看到 /，進入「可能是註解或除法」的狀態；看到下一個 / 就確認是行註解，一路吃到換行為止；看到 * 則進入區塊註解，直到遇見 */。看到 " 進入字串狀態，中間處理跳脫字元 \"。看到數字開頭進入數字狀態，允許小數點與指數記號。這種狀態機的實作效率極高，一次線性掃描即可完成，時間複雜度 O(n)，而且記憶體佔用可以做到很小。
但狀態機有個致命弱點：它沒有記憶。對於需要巢狀結構的語言（例如 JavaScript 的正規表達式字面值、Ruby 的 heredoc、Python 的多行字串、C++ 的 template），單純的狀態機無法正確判斷「這個 / 是除號還是 regex 的開頭」——那取決於前一個 token 是什麼，需要用更複雜的規則或回溯。這也是為什麼許多編輯器的詞法分析器會引入「上下文堆疊」來彌補。
實務上還有一個效能關鍵：增量詞法分析。編輯器不可能每次按鍵都重新掃描整個檔案（一個上萬行的檔案會明顯卡頓）。作法是只重新分析「受影響的範圍」，並且利用一個關鍵洞察：大部分 token 的型別只依賴它前面的 token。因此只要從修改點往前找到最近一個「狀態確定」的位置（通常是行首，或上一個未被改變的多行 token 的邊界），從那裡重新掃描到狀態穩定即可。多數編輯器會快取每一行的「起始狀態」，修改某一行後，只需重算這一行以及後續受影響的行。
3.2 語法分析與作用域：從 Token 到意義
詞法分析能告訴你「這是一個識別字」，但無法告訴你「這個識別字是變數還是函式」。要做到後者，需要語法分析（parsing）：把 token 序列組織成抽象語法樹（AST），再在樹上建立作用域與符號表。有了這些，編輯器才能回答：這個 user 是引用模組層級的常數，還是函式內的參數？這個 map 是陣列方法，還是使用者自訂的區域變數？
這一步的成本遠高於詞法分析。以 TypeScript 為例，完整解析一個大型專案需要讀入型別定義、處理泛型、展開交叉型別，時間與記憶體都以「秒」與「GB」為單位。這也是編輯器架構分歧的根源：詞法高亮可以即時、全檔案、無狀態地跑；語意高亮則必須是非同步、按需、有專案上下文的。
於是多數現代編輯器採用「兩階段渲染」：先同步跑詞法分析，立刻把顏色畫上去（使用者打字時感受到的是即時反應）；背景再啟動語言伺服器做語意分析，等結果回來後局部覆蓋原本的顏色（例如把某些變數改成「唯讀」或「已棄用」的樣式）。這種「先給你看草案，再慢慢修正」的策略，是互動系統設計的經典手法，也解釋了為什麼你剛打開一個大檔案時顏色會「跳一下」。
3.3 主題與樣式映射：分類到顏色的對照表
Token 分析完之後，下一步是把類別映射到樣式。這一層看似簡單，其實決定了 90% 的使用者體驗。以 TextMate 主題格式為例，一個主題本質上是一組「選擇器 → 樣式」的規則表：
keyword.control → 前景色 #C792EA、斜體
string.quoted.double → #C3E88D
comment.line → #546E7A、斜體
entity.name.function → #82AAFF
選擇器採用階層式命名（scope name），越往右越具體。這種設計的好處是「繼承」與「覆蓋」：你可以只定義 comment 的顏色，讓所有子類型的註解都套用；也可以針對 comment.documentation 特別指定另一種顏色。編輯器在渲染時，會為每個 token 找出「最匹配」的那條規則。
這裡有一個容易踩的坑：類別命名不統一。同一個「函式名稱」，在 JavaScript 語法裡可能叫 entity.name.function，在 Python 語法裡可能叫 meta.function-call，在 Rust 語法裡又是另一個名字。這導致一個主題在這三種語言中，函式名的顏色可能完全不同。這也是為什麼某些主題「在 JS 很好看，在 Python 卻很醜」——不是主題壞了，而是 scope 對不上。近年的 LSP 語意標記（semantic tokens）試圖用一套標準化的 token 型別（class、function、parameter、variable、property……）來解決這個問題，算是這個領域的重要進展。
3.4 增量更新與視窗化渲染
最後一層是渲染。一個常見的誤解是「編輯器把整個檔案都畫出來」，事實恰好相反：絕大多數編輯器只渲染視窗內可見的行，加上上下各一小段緩衝。這稱為視窗化渲染（viewport rendering）。對於一個十萬行的檔案，真正被轉成 DOM 節點或繪製指令的，可能只有螢幕上的五十行。
配合這個架構，高亮的計算也可以「懶惰化」：只計算可見範圍內的行。但這裡有個衝突——如果你把畫面捲動到一個從未分析過的位置，顏色就會延遲出現。因此實務上會做兩件事：第一，背景預先分析附近的行（例如可見範圍上下各 500 行）；第二，利用前面提到的行起始狀態快取，讓從任意位置開始的分析都能快速接續。
更講究的編輯器還會處理「水平視窗化」：一行超長的壓縮過的 JSON 或 minified JS，可能有幾十萬個字元。如果整行丟給詞法分析器，即使只有幾百個字元可見，也會造成卡頓。解法是在行內也做分段，只分析游標附近的區段。這種細節不容易被使用者察覺，但正是它決定了「這款編輯器順不順」。
四、主流技術路線比較：四種實作策略的取捨
4.1 正規表達式路線：快、簡單、但不準
最陽春的作法是對每一行套用一組正規表達式，依序匹配註解、字串、數字、關鍵字，然後上色。Sublime Text 早期的部分語法、許多線上程式碼區塊的顯示器（例如 Highlight.js 的某些語言定義）、以及無數自製小工具，都走這條路。
優點顯而易見：實作成本極低，加一個新語言只要寫幾條規則；效能通常也不錯，因為正規表達式引擎經過高度優化。缺點則是無法處理巢狀與上下文：它不知道字串裡面出現的 // 不是註解，也不知道多行字串會跨行，更無法區分「同一個字在型別位置與變數位置」的差異。結果就是偶爾出現整段程式碼被錯誤染色，而且錯誤會連鎖擴散（一個沒關好的引號，會讓後面幾百行全變綠色）。
不過要說句公道話：對於文件、Markdown、設定檔、簡短的程式碼片段，正規表達式路線的性價比極高。你不會為了一個顯示 20 行 YAML 的網頁，去引入一整套 Tree-sitter。
4.2 自建解析器路線：精準但昂貴
JetBrains 系列（IntelliJ IDEA、PyCharm、WebStorm）走的是另一條路：為每一種語言手寫一套完整的解析器，產生完整的 AST 與符號表，再基於這棵樹做高亮、補全、重構、導航。這條路線的準確度最高，因為它「真的理解」你的程式碼。
代價是驚人的工程量。支援一種語言，就要維護一套解析器、一套型別推導邏輯、一套索引機制，還要處理各種邊界情況。這也是為什麼 JetBrains 只支援相對少數的主力語言，而 VS Code 靠社群外掛覆蓋了上百種語言——後者是用「品質不齊」換「廣度」。
自建解析器還有一個架構上的挑戰：容錯。使用者的程式碼在打字過程中幾乎永遠是「不合法」的（少一個括號、少一個分號）。解析器必須能在語法錯誤的情況下仍然產出「盡量合理」的 AST，否則你一打錯字，整份文件的顏色就全崩了。這種「錯誤恢復（error recovery）」是解析器工程中最難的部分之一，也是學術與工業界持續研究的題目。
4.3 Tree-sitter：增量解析的折衷方案
2018 年前後，GitHub 推出的 Tree-sitter 改變了遊戲規則。它是一個用 C 寫成的解析器生成框架，語言定義採用類似 JavaScript 的文法描述檔，編譯成高效的 C 解析器。它最關鍵的三個特性是：
GitHub 用它來做程式碼搜尋與 diff 的語意分析，Atom 與 Neovim 用它做高亮，VS Code 也有相關擴充。對「想要比正規表達式準，又不想像 JetBrains 那樣養一整套 IDE」的專案來說，Tree-sitter 是目前最務實的選擇。它的限制是：解析結果只到語法層（syntactic），沒有型別資訊，所以「這個變數是區域還是全域」、「這個方法是不是已被棄用」這類問題仍然答不出來。
4.4 LSP 語意標記：把高亮變成語言伺服器的職責
最後一條路線是語言伺服器協定（LSP）的 semantic tokens。這個機制的核心思想是：不要在編輯器裡實作語言知識，而是讓編輯器向語言伺服器請求「這份文件裡哪些範圍屬於哪種語意類別」。伺服器回傳的是一串編碼後的整數陣列，描述「第 line 行、第 start 字元起、長度 length、型別為 function、修飾符為 static」。編輯器拿到之後，把它疊加在詞法高亮之上。
這條路線的優勢是資訊最豐富、來源最權威：語言伺服器擁有完整專案上下文，能正確判斷符號種類；而且一份伺服器可以同時服務多個編輯器（VS Code、Neovim、Emacs、Sublime 都能接）。缺點是成本與延遲：啟動伺服器要時間，第一次分析大型專案可能要好幾秒；而且並非所有語言都有成熟的伺服器實作，社群維護品質落差很大。
把四條路線放在一起看，會發現它們其實是同一條光譜上的不同點：左端是「快但不準」，右端是「準但貴」。現代編輯器的標準架構，是把光譜的兩端都放進去——用詞法或 Tree-sitter 做即時的第一層，用 LSP 做非同步的第二層。這種「分層、漸進、可降級」的設計，是互動式系統的通用智慧。
五、效能與正確性的取捨：那些不會寫在功能列表裡的事
在評測一款編輯器時，「支援語法高亮」是一句沒有資訊量的話——幾乎所有編輯器都支援。真正該問的是：它在多大的檔案上、多快的打字速度下、還能維持多少準確度？ 以下幾個維度值得特別注意。
第一，超大檔案的行為。 打開一個 50 MB 的日誌檔或一個自動生成的 minified JS，編輯器會怎麼做？有些會直接進入「純文字模式」並提示使用者，有些會硬撐但卡到無法使用，少數會做視窗化處理而保持流暢。這是辨別編輯器架構成熟度的試金石。
第二，多行結構的處理。 區塊註解、多行字串、heredoc、JSX、Markdown 中的程式碼區塊——這些都是「一行一行獨立分析」的天敵。你可以做個小測試：在一個字串裡打一個沒關閉的引號，看後面幾百行的顏色是否全部錯亂。會錯亂的，就是純行內分析；不會錯亂的，代表它有跨行狀態追蹤。
第三，輸入延遲。 在一個 5000 行的檔案裡連續快速打字，觀察顏色是否有可感知的延遲。理論上，增量分析應該讓每次按鍵的重新計算量維持在「幾行」的規模，延遲應在毫秒等級。如果你感覺到顏色「追不上」游標，通常表示分析管線沒有做好增量，或是在主執行緒上做了太重的計算。
第四，與其他功能的耦合。 高亮不是孤立的。自動縮排、括號配對、程式碼摺疊、錯誤標記、游標處的符號高亮（occurrences highlight），往往共用同一份分析結果。如果一款編輯器的高亮很準，但符號高亮很慢，通常表示它的分析結果沒有被妥善快取與重用——這是架構問題，不是設定問題。
第五，主題的一致性。 前面提過，scope 命名不統一會導致同一主題在不同語言中表現不一。你可以拿一個主題，分別打開 JS、Python、Go、Rust、HTML，看「函式名」和「變數名」是不是維持相似的視覺層級。一致性好的主題，代表它對多語言 scope 做了仔細的對應，這通常也反映出維護者的用心程度。
六、設計一個「好看又好用」的高亮主題
6.1 色彩層級：不要超過五到七個色相
新手設計主題最常見的錯誤，是「每個類別一個顏色」。關鍵字紅、字串綠、數字藍、函式黃、型別紫、運算子橘、參數青、常數粉……結果開啟檔案像聖誕樹，視覺系統忙著分類，反而增加負擔。認知科學的建議是：把語法類別壓縮成少數幾個「視覺權重層級」，同一個層級內的類別可以用同色系的不同明度或飽和度區分。
一個實用的分層方式大約是四到六層：
結構層（關鍵字、控制流）：最鮮明，因為它們決定程式的骨架。
資料層（字串、數字、布林、null）：中等鮮明，易於辨識但不搶戲。
識別層（變數、參數、屬性）：低調，因為它們數量最多、最常出現。
名稱層（函式、類別、型別）：中等，但用不同色相與識別層拉開距離。
雜訊層（註解、標籤、標點）：最淡，讓它們自然退到背景。
這種分層的好處是「掃視成本低」：你的眼睛一眼就能分辨「這是程式碼主體」還是「這是說明文字」，而不用逐一辨識每個 token 的類別。
6.2 對比與可及性：不要為了美觀犧牲可讀性
許多流行主題（尤其是深色主題）為了「柔和」而把前景色壓得很低，導致在低亮度螢幕或強光環境下幾乎看不清楚。WCAG 的建議是前景與背景的對比度至少 4.5:1，但對長時間閱讀的程式碼，實務上建議拉到 7:1 以上會更舒適。特別是註解顏色最容易出問題：很多主題把註解設成 #4A4A4A 這種「幾乎融入背景」的灰，結果需要閱讀註解時非常吃力。註解雖然是次要資訊，但仍然需要可讀。
另一個常被忽略的是色盲友善。紅綠色盲（約佔男性人口 8%）在「錯誤紅」與「成功綠」的區分上會有困難，而許多主題用紅綠來區分刪除與新增、錯誤與通過。比較穩健的作法是：不要只靠色相，同時用明度、字重、底線或圖示來編碼。這在 diff 視圖與診斷訊息中尤其重要。
還有一點是主題與環境的匹配。深色主題在昏暗環境下舒適，但在強光下容易反光；淺色主題在日間閱讀舒服，但夜間可能太刺眼。這也是為什麼成熟的編輯器會提供「依系統外觀切換」的功能。從人因工程的角度，這不是花俏，而是減少眼睛負擔的實際手段。
七、常見誤區與實務建議
最後，整理幾個在論壇討論中經常出現的誤解，以及對應的實務建議。
誤區一：「顏色越多代表功能越強」。 恰恰相反。成熟的編輯器通常會刻意收斂顏色數量，把視覺資源集中在真正重要的區別上。當你發現某個編輯器把每個 token 都染成不同顏色，那往往不是因為它分析得細，而是因為它分不清主次。
誤區二：「高亮錯誤就是編輯器爛」。 要先確認是哪一層出錯。如果是「字串裡的註解符號被染色」，那是詞法層的問題；如果是「同名變數在不同作用域顏色一樣」，那是語意層尚未就緒（可能只是語言伺服器還在載入）。兩者的嚴重程度與可修復性完全不同。
誤區三：「主題只是個人偏好，跟生產力無關」。 研究上很難直接量化，但從前注意處理與視覺搜尋的機制來看，顏色層級分明的主題確實能降低掃視成本。建議的做法不是盲目跟風熱門主題，而是用自己最常寫的三種語言實際試用一週，觀察眼睛疲勞程度與找錯速度。
誤區四：「一定要用最精準的解析器」。 對 90% 的日常編輯情境，Tree-sitter 等級的語法高亮已經綽綽有餘；真正需要型別級精準度的，是重構、跨檔案導航、批次修改這些功能，而它們本來就會呼叫更重的語言伺服器。把「高亮」和「語意分析」解耦，是現代編輯器架構最重要的設計決策之一。
如果要給出幾條可直接操作的建議：
選擇支援增量解析的編輯器，並在大型檔案上實測輸入延遲。
為不同語言設定不同主題或不同字型，強化情境切換的視覺提示。
結語：顏色是介面，分析才是本體
回到最初的問題：為什麼語法高亮？表面答案是「好看、好讀」，但真正的答案是——它是一個把程式結構翻譯成人類視覺系統語言的介面。編譯器看的是語法樹，人眼看的是一行一行的文字；語法高亮的工作，就是在這兩者之間搭一座橋，讓你不用在腦中重建整棵樹，就能感知程式的形狀。
而支撐這座橋的，是一條從詞法分析、語法分析、作用域解析，到主題映射與增量渲染的完整管線。每一層都有它的取捨：狀態機快但沒有記憶，完整解析準但昂貴，Tree-sitter 折衷，LSP 權威但延遲。現代編輯器的成就，不在於選了哪一種，而在於把它們分層組合、漸進增強、優雅降級——先給你即時的草案，再慢慢補上精確的細節。
下次當你在 雅寶社區 · 頂客論壇 看到有人爭論「哪個編輯器的高亮比較好」時，不妨把問題拆細一點：是詞法層的準確度？是語意層的覆蓋率？是主題的色彩設計？還是超大檔案下的效能表現？當你分得清這些層次，評測就不再是「我覺得比較順眼」，而是有依據的工程判斷。而這，也正是我們在這個版上討論軟體時，最想追求的東西。
顏色只是介面，分析才是本體。理解了這一點，你就會明白為什麼一個看似「只是換換顏色」的功能，值得用四千多字來拆解——因為它其實是編輯器整個語言理解能力的縮影。
本文由雅寶社區 · 頂客論壇軟體評測版編輯整理，歡迎在討論區分享你的實測經驗與主題推薦。
```