vscode-textmate 解析变慢的主因是低效分词：每行重解析、嵌套规则与未优化正则导致时间复杂度飙升；应优化 patterns 顺序、收紧 injectionSelector、避免贪婪匹配，并通过性能面板定位耗时 rule。
为什么 vscode-textmate 解析会变慢
语法高亮卡顿、大文件滚动延迟、输入时高亮滞后——这些现象背后，往往不是主题或渲染问题，而是 vscode-textmate 在做低效的分词（tokenization）：它对每行都重新从头开始解析，遇到嵌套 begin/end 规则、大量 injection 语法或正则回溯时，时间复杂度可能飙升。尤其当你的 .tmLanguage.json 里存在未优化的捕获组、贪婪匹配或跨行 lookahead，性能下降会非常明显。
关键配置项：injectionSelector 和 patterns 顺序影响巨大
TextMate 语法是“自顶向下、深度优先”匹配的，patterns 数组里的规则顺序直接决定匹配路径长度。高频触发的规则（如注释、字符串）应放在前面；低频或开销大的规则（如多行正则、嵌套注入）必须后置。更关键的是注入语法：injectionSelector 若写成 source.js 这种宽泛作用域，会导致整篇 JS 文件所有 token 都被反复检查是否要注入——实际只需限定到 meta.embedded.block.html 这类具体上下文。
- 错误写法：
"injectionSelector": "source.js"→ 每个 JS token 都进一次注入判断 - 正确写法：
"injectionSelector": "meta.tag.inline.any.html source.js"→ 只在 HTML 标签内 JS 片段中启用 - 避免
.*或^.*$类全局正则；用\b(if|else|while)\b替代[a-zA-Z]+匹配关键字
如何验证分词瓶颈：用 Developer: Toggle Developer Tools 抓帧
VS Code 内置性能面板能直接暴露 vscode-textmate 的耗时点。打开开发者工具 → Performance 标签 → 点击录制 → 在大文件中快速滚动或输入几行代码 → 停止录制 → 筛选关键词 tokenize 或 parseRule。你会看到具体哪个 rule 的 match 函数占用了最多 CPU 时间。
- 若某条
begin/end规则反复出现在火焰图顶部，说明它在频繁重匹配，需拆解或加锚点^ - 若
injectFrom相关调用密集，确认是否误启了不必要的注入语法 - 注意
repository中复用的 rule 是否被多次 include —— 每次 include 都是一次独立解析开销
真正有效的提速手段：预编译 + 范围限制
vscode-textmate 本身不支持 JIT 编译，但你可以通过构建时预处理降低运行时负担。社区已有实践：用 vscode-tmgrammar 工具把 .cson 或 .yaml 语法转为精简的 .tmLanguage.json，自动剔除未引用的 repository 条目、扁平化嵌套 patterns、将常量正则提取为命名捕获组。更重要的是，在语言扩展中主动限制分词范围：
- 在
package.json的contributes.languages里设置"configuration": "./language-configuration.json"，其中指定"comments": { "lineComment": "//", "blockComment": ["/*", "*/"] }，让编辑器跳过对注释内容的深度 token 化 - 对超长行（如 base64 字符串），用
maxLen属性在 grammar 中截断匹配："match": "(? → 改为 <code>"match": "(? - 禁用非必要注入：比如 Markdown 扩展默认注入 JS/CSS，若你项目不用内联脚本，就在
grammars/markdown.tmLanguage.json中删掉对应injectionSelector块
最易被忽略的一点：语法文件体积本身就会拖慢加载。一个超过 500KB 的 .tmLanguage.json，光是 JSON.parse 就要几毫秒——把它拆成主 grammar + 按需加载的 repository 外部文件，配合 vscode-textmate 的 lazy load API，才能真正释放性能余量。
