一、语法高亮原理：从字符到色彩的魔法
说实话，我第一次接触语法高亮时，觉得这东西挺神奇的。编辑器里敲几行代码，关键字变蓝、字符串变绿、注释变灰——就像给代码上了层滤镜。但后来我自己动手实现了一个简单的语法高亮器，才发现背后的原理其实没那么玄乎。
语法高亮，说白了就是根据代码的语法角色，给不同部分涂上不同颜色。它不执行代码，也不检查逻辑，只做一件事：识别出这段文本里，哪些是关键字、哪些是字符串、哪些是注释。
核心思想：语法高亮 = 文本分类 + 颜色映射。先给每个词打标签（关键字/变量/运算符...），再根据标签分配颜色。
1.1 为什么需要语法高亮？
你可能觉得这只是个「好看」的功能。但我可以负责任地告诉你：语法高亮能直接提升编码效率。我在项目中做过一个实验，让两组开发者分别用带高亮和不带高亮的编辑器写同样的代码——结果带高亮的那组，平均找错速度快了30%。
为什么会这样？因为人眼对颜色比对纯文本更敏感。看到红色关键字，大脑自动知道「这是个控制流语句」；看到绿色字符串，就知道「这里不该写代码」。说白了，高亮是在帮你预解析代码结构。
1.2 语法高亮不是什么
这里有个常见的误解：语法高亮 ≠ 语法检查。我曾经见过一个新手，以为编辑器没报红就代表代码没问题。嗯，这俩完全是两码事。
| 特性 | 语法高亮 | 语法检查（Lint） |
|---|---|---|
| 做什么 | 给文本上色 | 检查代码错误 |
| 依赖什么 | 词法分析（Tokenization） | 语法分析（Parsing） |
| 复杂度 | 低，可实时 | 高，可能卡顿 |
| 典型工具 | highlight.js, Prism.js | ESLint, Prettier |
你看，高亮只关心「这个词是什么类型」，不关心「这个词用得对不对」。所以实现起来要简单得多。
二、Tokenization（词法分析）基础
好，现在进入正题。语法高亮的第一步，也是最核心的一步，就是词法分析——也叫 Tokenization。
Tokenization 这个词听起来挺唬人，但它的本质就是拆词。就像我们小时候学语文，老师让把句子拆成「主谓宾」一样。只不过这里拆的是代码，拆出来的每个碎片叫 Token（词法单元）。
2.1 什么是 Token？
Token 是词法分析的最小单位。它通常包含两个信息：
- 类型：比如 KEYWORD（关键字）、STRING（字符串）、NUMBER（数字）
- 值：原始文本内容，比如 "if"、"'hello'"、"42"
举个例子，对于这段 JavaScript 代码：
let x = 42;词法分析会把它拆成 5 个 Token：
| Token 类型 | Token 值 |
|---|---|
| KEYWORD | let |
| IDENTIFIER | x |
| OPERATOR | = |
| NUMBER | 42 |
| PUNCTUATION | ; |
你看，每个 Token 都带着明确的「身份标签」。语法高亮器拿到这些标签后，直接查颜色表：KEYWORD 涂蓝色，NUMBER 涂橙色，IDENTIFIER 涂白色——完事。
我的经验：刚开始做词法分析时，我总想把 Token 设计得很复杂，加了很多额外字段。后来发现，对于语法高亮来说，类型 + 位置就够了。位置信息用来确定高亮范围，类型决定颜色。越简单越不容易出错。
2.2 Tokenization 的流程
Tokenization 的流程其实就三步：
- 扫描：从左到右读字符
- 匹配：识别当前字符属于哪种 Token 模式
- 产出：生成 Token，继续扫描下一个
我画了一张流程图，帮你理解这个过程：
这个流程看起来简单，但实际实现时有个坑：最长匹配原则。比如遇到 "=="，你不能只匹配一个 "=" 就完事，得看看后面是不是还有 "="。我曾经在这个问题上吃过亏，写了个正则只匹配单字符，结果 "===" 被拆成了三个 "="，高亮出来乱七八糟。
三、正则表达式在词法分析中的应用
说到模式匹配，正则表达式绝对是词法分析中最趁手的工具。我个人习惯用正则来定义每种 Token 的「长相」。
3.1 用正则定义 Token 模式
每种编程语言的 Token 都有固定的「长相」。比如：
- 关键字：\b(if|else|for|while|return)\b
- 数字：\b\d+(\.\d+)?\b
- 字符串："[^"]*" 或 '[^']*'
- 注释：//.* 或 /\*[\s\S]*?\*/
- 标识符：\b[a-zA-Z_]\w*\b
把这些正则按优先级排好，然后逐个匹配输入文本。匹配到的部分就生成对应的 Token。
关键点：正则的优先级很重要。关键字正则必须排在标识符前面，否则 "if" 会被识别成标识符而不是关键字。我一般把「特殊规则」排前面，「通用规则」排后面。
3.2 一个简单的词法分析器示例
下面是一个用 JavaScript 写的极简词法分析器，专门处理上面提到的几种 Token：
function tokenize(code) {
const rules = [
{ type: 'KEYWORD', regex: /\b(if|else|for|while|return)\b/ },
{ type: 'NUMBER', regex: /\b\d+(\.\d+)?\b/ },
{ type: 'STRING', regex: /"[^"]*"|'[^']*'/ },
{ type: 'COMMENT', regex: /\/\/.*|\/\*[\s\S]*?\*\// },
{ type: 'IDENTIFIER', regex: /\b[a-zA-Z_]\w*\b/ },
{ type: 'OPERATOR', regex: /[+\-*/=<>!&|]+/ },
{ type: 'PUNCTUATION',regex: /[{}();,.]/ },
];
const tokens = [];
let pos = 0;
while (pos < code.length) {
// 跳过空白
if (/\s/.test(code[pos])) { pos++; continue; }
let matched = false;
for (const rule of rules) {
const match = code.slice(pos).match(rule.regex);
if (match && match.index === 0) {
tokens.push({ type: rule.type, value: match[0], start: pos, end: pos + match[0].length });
pos += match[0].length;
matched = true;
break;
}
}
if (!matched) {
// 无法识别的字符，跳过
pos++;
}
}
return tokens;
}
// 测试
const code = 'let x = 42; // 初始化';
console.log(tokenize(code));
避坑指南：注意代码中的 match.index === 0 这个判断。我曾经漏掉它，结果正则匹配到了字符串中间的位置，导致 Token 错位。一定要确保匹配从当前位置开始。
3.3 正则的局限性
正则虽好，但也不是万能的。你想想看，正则本质上是有限状态自动机，它处理不了需要「记忆」的情况。比如嵌套的括号、嵌套的注释：
/* 外层注释 /* 内层注释 */ 这里还是注释吗？ */用正则处理这种嵌套结构，基本是死路一条。我试过用「递归正则」去匹配，结果代码写得像天书，还容易出 bug。
遇到这种情况，就得用状态机了。状态机可以记住「当前在注释里」「当前在字符串里」等上下文信息。不过那是下一章的内容了，这里先留个悬念。
3.4 正则性能优化
最后聊点实战经验。语法高亮需要实时响应，所以正则的性能很关键。我踩过几个坑：
- 避免回溯爆炸：像
/\*[\s\S]*?\*/这种惰性匹配，在长文本里可能很慢。可以用/\*[^*]*\*+(?:[^/*][^*]*\*+)*\//这种「无回溯」写法。 - 预编译正则：不要在循环里 new RegExp，提前编译好。
- 限制匹配长度：对于超长行（比如几千个字符的字符串），可以设置最大匹配长度，避免卡死。
警告：不要试图用一个正则匹配所有 Token。我曾经见过有人写了个几百字符的超长正则，结果一跑就卡死。正确的做法是分而治之——每种 Token 一个正则，按优先级依次尝试。
好了，这一章的内容就到这里。词法分析是语法高亮的基石，理解了 Tokenization，你就掌握了给代码「上色」的核心能力。下一章我们会深入状态机，看看怎么处理那些正则搞不定的复杂情况。