最近在做一个在线代码编辑器的项目，用到了 CodeMirror 6。其中一个核心需求是实现自定义关键词的高亮，比如高亮项目里特定的 API 名称或者错误信息。一开始觉得这应该很简单，但真正做起来，尤其是在处理大文件或者复杂匹配规则时，遇到了不少性能瓶颈和配置上的“坑”。今天就把我摸索出来的这套从基础配置到性能优化的实战经验分享给大家，希望能帮你少走弯路。
1. 背景痛点：为什么默认方案不够用？
CodeMirror 本身提供了强大的语法高亮能力，通常通过定义语言模式（Language Mode）和词法分析器（Tokenizer）来实现。但对于我们这种“非标准”的关键词高亮需求——比如只想高亮文档中出现的几个特定业务词汇——如果直接修改或新建一个完整的语言模式，就显得太重了。
更关键的是性能问题。在 CodeMirror 6 之前的版本，常用的addOverlay方法虽然直观，但在处理大型文档（比如上万行）或动态变化的高亮规则时，其全量扫描和重绘的机制很容易导致编辑器卡顿，用户体验直线下降。即使是在 CodeMirror 6 的架构下，如果实现方式不当，频繁的视图更新（View Update）和装饰器（Decoration）计算也会成为性能瓶颈。
2. 技术选型：标记器 vs. 装饰器
在 CodeMirror 6 的生态里，实现文本高亮主要有两种思路：
方案一：基于标记器（Tokenizer / Language）这种方式是“正统”的语法高亮路径。你需要定义一个Language对象，并实现其token方法。在这个方法里，你可以编写逻辑来识别你的关键词并返回对应的样式标记（Token）。
- 优点：与编辑器的语法高亮系统深度集成，行为一致，对于需要复杂状态（如嵌套注释）的场景支持好。
- 缺点：实现相对复杂，需要理解流式解析（Stream Parser）或状态机。更重要的是，它通常作用于整个语言范围，如果只是为了高亮几个独立关键词而替换整个语言的解析逻辑，可能不划算，且会影响编辑器内置的该语言其他语法的高亮。
方案二：基于装饰器（Decorator / View Plugin）这是更灵活、更轻量的方式。你可以创建一个ViewPlugin，监听文档变化（EditorView.update），在回调中计算哪些位置需要高亮，然后通过DecorationSet来管理这些高亮标记，最后通过view.dispatch更新编辑器视图。
- 优点：实现直观，与文档内容解耦，可以独立于任何语言模式工作。非常适合动态增减高亮规则、高亮搜索结果或特定标记的场景。
- 缺点：需要手动管理装饰器的生命周期和更新逻辑，在文档变化频繁时，计算效率至关重要。
对于我们的“自定义关键词高亮”场景，基于装饰器的方案通常是更合适的选择。它足够轻量，也给了我们充分的控制权来进行性能优化。
3. 核心实现步骤
下面我们一步步来实现一个高效的关键词高亮插件。
第一步：定义高亮规则和样式首先，我们需要定义要匹配哪些关键词，以及它们对应的样式。
// 定义单个高亮规则 interface HighlightRule { regex: RegExp; // 用于匹配关键词的正则表达式 class: string; // 对应的 CSS 类名 } // 高亮插件配置项 interface HighlightPluginConfig { rules: HighlightRule[]; caseSensitive?: boolean; // 是否区分大小写 }对应的 CSS 需要定义好这些类名，例如：
.cm-highlight-keyword { background-color: #fff3cd; color: #856404; font-weight: bold; }第二步：创建计算装饰器的核心函数这个函数负责扫描给定文档范围（通常是从头到尾），根据规则找到所有匹配项，并创建对应的装饰器（Decoration.mark）。
import { RangeSetBuilder } from '@codemirror/state'; import { Decoration } from '@codemirror/view'; function computeDecorations(view: EditorView, config: HighlightPluginConfig): DecorationSet { const builder = new RangeSetBuilder<Decoration>(); const { rules } = config; const text = view.state.doc.toString(); // 遍历所有规则 for (const rule of rules) { let match; // 注意：使用 `RegExp` 的 `lastIndex` 进行循环以正确处理全局匹配 const regex = new RegExp(rule.regex.source, `g${config.caseSensitive ? '' : 'i'}`); while ((match = regex.exec(text)) !== null) { // match.index 是匹配开始的字符索引 const from = match.index; const to = from + match[0].length; // 确保匹配位置在文档有效范围内（理论上应该总是在） if (from >= 0 && to <= text.length) { // 创建一个装饰器标记 const decoration = Decoration.mark({ class: rule.class, }); builder.add(from, to, decoration); } } } return builder.finish(); }第三步：创建 ViewPlugin 并管理状态这是插件的核心，它将计算函数与编辑器视图的生命周期绑定起来。
import { ViewPlugin, ViewUpdate, EditorView } from '@codemirror/view'; import { Extension } from '@codemirror/state'; class HighlightPlugin { decorations: DecorationSet; constructor(view: EditorView, private config: HighlightPluginConfig) { // 初始化时计算一次装饰器 this.decorations = computeDecorations(view, config); } update(update: ViewUpdate) { // 性能关键：只在文档内容改变或配置改变时才重新计算 if (update.docChanged || update.viewportChanged) { this.decorations = computeDecorations(update.view, this.config); } } } // 工厂函数，用于创建插件实例 const highlightPlugin = (config: HighlightPluginConfig): Extension => { return ViewPlugin.fromClass( HighlightPlugin, { decorations: (v) => v.decorations, // 告诉 CodeMirror 从这个实例的 `decorations` 属性获取装饰集 } ); };第四步：使用插件现在，你可以像使用其他 CodeMirror 扩展一样使用它了。
import { basicSetup } from 'codemirror'; import { javascript } from '@codemirror/lang-javascript'; const editor = new EditorView({ doc: `// 示例代码 function helloWorld() { console.log('Hello, World!'); // 让我们高亮一下 error 和 warn const error = new Error('test'); console.warn('This is a warning'); }`, extensions: [ basicSetup, javascript(), highlightPlugin({ rules: [ { regex: /\berror\b/gi, class: 'cm-highlight-error' }, // 高亮单词 error { regex: /\bwarn\b/gi, class: 'cm-highlight-warn' }, // 高亮单词 warn ], }), ], parent: document.body, });4. 性能优化实战
上面的基础实现已经可以工作，但在大文档下，每次docChanged都全文档扫描RegExp是灾难性的。以下是几个关键的优化策略：
优化点一：仅计算可视区域（Viewport）对于超大文档，我们可能只需要高亮用户当前能看到的部分。CodeMirror 的update.viewportChanged给了我们提示。
update(update: ViewUpdate) { // 判断是否需要更新：文档内容变化 或 可视区域变化 且 配置可能变化（这里简化处理） let shouldUpdate = update.docChanged; // 如果只是滚动（viewport变化），我们也重新计算可视区域的高亮，这比计算全文快得多 if (update.viewportChanged && !update.docChanged) { shouldUpdate = true; // 可以在这里实现一个只计算 viewport 内装饰器的函数 // this.decorations = computeDecorationsInViewport(update.view, this.config); } // 为了简单，这里仍然全量计算，但实际项目强烈推荐 viewport 优化 if (shouldUpdate) { this.decorations = computeDecorations(update.view, this.config); } }优化点二：防抖与增量更新如果用户正在快速输入（比如粘贴大段代码），可能会在极短时间内触发多次update。我们可以使用防抖（debounce）或节流（throttle）来合并这些更新请求，避免不必要的计算。
更高级的做法是增量更新：只重新计算受编辑操作影响的那部分文档的装饰器。这需要更复杂的逻辑来分析update.changes（一个ChangeSet对象），判断哪些文本范围被插入、删除或替换，然后只更新这些范围及其可能影响到的周边区域的高亮。
优化点三：优化正则表达式与匹配逻辑
- 预编译正则：在插件初始化时，根据配置的
caseSensitive预编译好所有正则表达式，避免在每次计算时重复new RegExp。 - 合并规则：如果可能，将多个规则合并成一个更复杂的正则表达式，通过捕获组来区分不同的关键词，这样只需要遍历文档一次。但这会牺牲一些灵活性和可读性。
- 使用字符串的
indexOf进行简单匹配：对于纯字符串关键词（无正则元字符），使用indexOf循环可能比正则exec更快，尤其是关键词很多的时候。
优化点四：使用 Worker 进行后台计算对于极其庞大的文档和复杂的规则，计算装饰器可能是一个耗时操作（>50ms）。为了避免阻塞主线程导致编辑器无响应，可以将文本内容和规则发送到 Web Worker 中进行匹配计算，完成后将结果（匹配的位置和类型）传回主线程再创建装饰器。这需要处理异步状态和可能的竞态条件（比如计算还没完成，文档又发生了变化）。
5. 避坑指南
- 避免频繁
dispatch：在ViewPlugin的update方法中，不要直接调用view.dispatch。我们的decorations属性会被 CodeMirror 自动读取并应用。手动dispatch会导致循环更新。 - 处理异步更新的竞态条件：如果采用了 Worker 或其它异步计算，一定要为每次计算关联一个版本号或唯一 ID。当异步结果返回时，检查它是否对应于编辑器当前最新的文档状态，如果不是，则丢弃旧结果。
- 大型文档分块高亮：结合“仅计算可视区域”的策略。当用户滚动时，动态计算新进入视口的区域的高亮。可以为尚未计算的区域提供一个“加载中”的占位样式。
- 装饰器的特异性：确保你的高亮 CSS 类名具有足够高的特异性，或者使用
!important，以避免被编辑器主题或其他插件的样式覆盖。 - 内存管理：
DecorationSet会占用内存。如果高亮规则被动态清空，确保将this.decorations设置为Decoration.none，以释放资源。
6. 总结与延伸
通过以上步骤，我们实现了一个兼顾功能与性能的 CodeMirror 关键词高亮插件。其核心思路是：使用ViewPlugin管理基于装饰器的高亮状态，并在update方法中智能地决定何时以及如何重新计算装饰器，同时运用多种策略（如视口计算、防抖、Worker）来优化性能。
这种基于装饰器的模式非常强大，你可以很容易地将它扩展到其他场景：
- 搜索高亮：将搜索词作为动态规则传入。
- 代码错误波浪线：根据 Linter 的结果，创建
Decoration.widget在行尾添加错误图标，或者用Decoration.mark画波浪下划线。 - 代码折叠标记：在可折叠代码块的开始行添加一个折叠按钮控件。
- 实时协作光标：显示其他协作者的光标位置和选区。
思考题：
- 如果我们需要高亮的关键词不是固定的，而是可以通过一个输入框动态添加和删除的，插件架构应该如何调整，以保证规则变化后高亮能立即更新且性能良好？
- 在上述实现中，如果两个高亮规则匹配到了文档的同一段文本（重叠），会发生什么？CodeMirror 会如何处理？如果你希望后匹配的规则覆盖先匹配的，或者希望它们叠加，应该如何实现？
希望这篇笔记能帮助你顺利在 CodeMirror 中实现高效的关键词高亮功能。编辑器优化是一个深水区，每一点性能提升都能显著改善用户体验，值得细细打磨。
