基于GapBuffer的标记管理算法：解决文本编辑器卡顿实战

1. 项目概述：为什么一个光标的文本编辑器会卡

事情得从一次真实的线上反馈说起。有用户抱怨说，在某个文档编辑器里快速输入中文时，偶尔会出现明显的“打字掉帧”，尤其是文档里高亮标记变多之后，每次敲键都能感觉到停顿。一开始怀疑是渲染线程的问题，后来逐步排查，最后定位到标记管理逻辑上——编辑器内部的标记表在每次文本变更时都要做一轮全量更新，数据量一大，就成了性能瓶颈。

这里说的“标记管理”，是文本编辑器里非常核心但又极其容易被忽视的一块。文档里那些高亮关键词、选区记录、断点位置、折叠范围、拼写错误波浪线，本质上都是一些附加在文本上的位置信息。用户在编辑文本时，增删字符都会导致后续所有位置发生变化，所以标记表必须跟着文本一起“移动”。如果标记数量达到几千甚至上万，并且每次输入都要把所有标记重新计算一遍，卡顿就不可避免。

这个项目实现的目标很简单：在 GapBuffer 这种数据结构之上，设计一套高效的标记管理算法，让标记的移动、查询、批量更新都做到与文本编辑复杂度解耦，无论标记有多少，影响都被限制在局部。最终实测下来，在包含大量标记的长文档里，连续输入时编辑器的主线程耗时下降了约 90%，标记查询耗时趋近于常数级别。

这篇内容适合所有自己动手写过编辑器、词法分析器、在线代码高亮工具的人，也适合对数据结构在实际工程中的应用感兴趣的读者。我会把 GapBuffer 的基础讲清楚，然后重点拆解在这之上做标记管理的完整思路、数据结构设计和实操过程，顺便把调试过程中踩过的坑也一并说出来。

2. 为什么选 GapBuffer：编辑器的数据结构选择题

2.1 文本编辑器数据结构的常见选项

先花一点时间回顾一下文本编辑器的底层数据结构选型，因为标记管理算法的设计高度依赖底层存储结构的行为特性。

现代编辑器里，主流的文本表示方案大概有四种：数组（Array）、GapBuffer（间隙缓冲区）、PieceTable（片段表）、Rope（绳索树）。数组方案最简单，插入和删除都是 O(n) 级别的内存搬移，适合非常短的文本。GapBuffer 是数组的改良版，它在缓冲区中间留出一段“空洞”，让插入和删除的摊还复杂度降到接近 O(1)。PieceTable 则是把文本拆成多个片段进行管理，通过片段引用来避免大块搬移，很多现代编辑器比如 VS Code 的核心文本模型就用了这种思路。Rope 则是用树结构来管理大文本，适合极度庞大的文档和并发场景。

选择 GapBuffer 而不是其他方案，主要基于项目本身的定位——这是一个中等体量、单线程编辑、需要轻量级实现的项目。GapBuffer 的代码量小、占用内存低、实现直观，而且它的局部编辑特性非常契合标记管理的需求：gap 附近的文本变动只会影响缓冲区周边区域，远处的内容天然不受影响。

这里就引出了标记管理的一个核心矛盾：文本底层的操作是局部的，但标记表通常是全局存储的。如果每次局部编辑都要全局扫描标记，底层的局部性优势就被标记层完全抵消了。所以好的标记管理算法，核心目标就是“让标记的更新也变成局部操作”，让底层数据结构和上层标记表的行为特性保持一致。

2.2 GapBuffer 的基础结构与核心操作

GapBuffer 本质是一个字符数组，外加两个关键指针：gapStart 和 gapEnd。gap 就是缓冲区中一段未使用的空洞区域，它把文本分成左右两部分，左边是已经使用的字符，右边也是已使用的字符，中间是闲置空间。当光标在某个位置插入字符时，先把 gap 移动到光标位置，然后把字符写进 gap 的头部，gapStart 前进一位。删除字符时，反向操作，把要删除的字符覆盖掉，gap 变大。

Gap 的移动是 GapBuffer 性能的关键所在。比如光标要从位置 100 跳到位置 2000，gap 就要从当前位置“搬”到目标位置，这时需要把中间的字符一块块地拷贝过去。这个过程单次是 O(n) 的，但因为编辑操作通常带有局部性——用户连续输入时，光标不会大范围跳跃——所以摊还成本很低。

GapBuffer 还有一个很好的特性：文本内容在内存中的物理顺序不是连续的，但逻辑顺序是连续的。这意味着，如果你持有某个字符的逻辑位置（即相对于文档开头的字符偏移量），在文本被编辑后，这个偏移量可能会失效——这就是标记管理的难点。

用生活化的方式理解 GapBuffer 的结构：想象一排书架，你特意在中间空出一格不放书。如果要往书架中间插一本新书，你只需把空位旁边的书往后挪一点点，而不是把整排书全部重摆一遍。这个空位就是 gap，挪书的动作就是 gap 移动。

3. 标记管理到底在管什么

3.1 标记的类型与特征

在开始设计算法之前，先明确标记到底是什么。标记本质上是“锚定在文本位置上的额外信息”，它通常包含三个要素：位置信息、绑定策略、业务数据。位置信息通常是一个整数偏移量，表示这个标记指向文档中的第几个字符；绑定策略决定了文本编辑时标记如何跟随；业务数据则是标记携带的附加信息，比如高亮的颜色、折叠的深度、断点的状态等。

绑定策略一般分为两种：左绑定和右绑定。左绑定意味着标记固定在它左侧的字符上，如果这个标记的位置被插入新文本，标记不移动；右绑定则相反，标记固定在右侧字符上，插入文本时标记跟着右侧一起右移。举个例子，一个断点标记如果绑定在某个代码行首，那么在这一行前面插入新行时，断点不应该跟着跑，所以这个断点应该是左绑定；而一个选区起点标记，则通常需要右绑定，因为用户在起点处输入文字时，选区的起点应该往右扩展。

项目中遇到的标记类型主要是高亮标记。这类标记有明确的起止位置，需要维护成对的结构，而且数量可能非常大。一个 10 万行的代码文件，如果做了充分语法高亮，标记数量达到几万个很正常。这种情况下，标记的存储和更新就不能用简单的线性扫描了。

3.2 一般的糟糕做法与项目痛点

很多编辑器实现里，标记管理用的是最直接的方法：维护一个数组，每个元素存一个位置偏移量。文本每次变更时，遍历整个数组，把受影响的标记全部重新计算。这个做法的优点是实现简单，但性能瓶颈非常明显。

假设一个文档有 3 万个标记，用户在位置 10000 处插入了一个字符。这意味着所有位置大于等于 10000 的标记，偏移量都要加 1。遍历 3 万个标记，每个做一次数值加法和写回，本身不算太慢，但问题是编辑器里每次按键都可能触发多次文本变更——键盘输入、IME 组合、自动补全、格式化——每个变更都触发一次全表扫描，累积起来就非常可观了。更糟糕的是，如果同时存在高亮实时更新、选区同步、折叠验证等多套标记系统，每个系统各做一遍全量遍历，性能就直接崩盘。

我之前在调试那个“中文输入掉帧”问题的时候，做过一次性能剖析，结果让我印象很深：一次普通的汉字输入，IME 会拆成多个插入片段，每个片段都会触发文本变更事件。每个变更事件里，高亮标记模块要遍历一次全量标记表，折叠模块也要遍历一次，选区同步还要遍历一次。一次按键，可能就造成了近十万次无意义的位置判断。这就是卡顿的根源。

所以，这个项目的核心目标可以提炼成一句话：设计一个标记管理算法，让文本变更时标记的更新时间只与受影响区间内的标记数量成正比，而不是与全部标记数量成正比。

4. 核心数据结构设计：有序标记表与双向链表

4.1 有序标记表：按位置排序的标记集合

GapBuffer 的标记管理算法里，最核心的数据结构是一个有序标记表。它按标记在文档中的位置升序排列，每个节点都包含标记的偏移量、绑定策略、业务数据指针。这个表的物理结构采用双向链表，每个节点有一个 prev 指针和一个 next 指针。

为什么选双向链表而不是数组？核心原因是文本编辑的局部性特性。用户在某个位置连续输入时，只会影响该位置附近的标记，链表能做到局部插入和删除——只需要调整受影响节点的指针，不需要像数组那样搬移后方的所有元素。另一个原因是 GapBuffer 本身是局部优化的，链表天然匹配这种局部性逻辑。

但这个链表不是普通的链表，它有一个非常关键的内部约定：每个节点记录的偏移量，是相对于“文档起始位置”的绝对偏移量。也就是说，只要文本被编辑，理论上所有存在于编辑位置之后的节点偏移量都需要变动。如果老老实实地逐个更新，性能就会回到 O(n)。

解决思路是“不更新”。这个看似矛盾的思路，恰恰是整个算法设计的精髓——通过引入 GapBuffer 的 gap 迁移机制，把“更新所有节点”转化为“更新源头”，用惰性的方式避免全局调整。

4.2 Gap 回退机制：把标记表当作带 gap 的数组

我在设计算法时反复折腾了很久，最后发现一个非常巧妙的思路：既然 GapBuffer 本体是一个带 gap 的数组，那么标记表也可以被设计成一套“带 gap 的位置记录系统”。这个设计不再用传统意义的有序表，而是把标记节点的逻辑坐标建立在一个“虚拟文档坐标系”上，并与 GapBuffer 的实际偏移量建立一个延迟映射。

具体来说，每个标记节点不直接存储当前文档的绝对偏移量，而是存储“相对于文档实际内容稳定端的偏移量”。当文本在某个位置发生插入时，我们不需要去更新所有后方节点，只需要把 GapBuffer 的 gap 位置同步到标记表的“gap 位置”上。这样，标记表内部的相对位置关系不会因为文本插入而失效——因为 GapBuffer 的 gap 划开的位置，与标记表 gap 划开的位置始终一致。

这个设计的本质，是让 GapBuffer 的“间隙”概念向标记层延伸，让标记表在逻辑上成为 GapBuffer 内容结构的一个“投影”。因此，当文本插入发生时，只有标记表中落在 gap 附近的标记真正需要调整，后方的标记完全不受影响。

这里需要一定的抽象思维才能理解。我用一个类比来说明：想象有一列排队的人，每个人的手里都拿着一张纸条，纸条上写着“我是第几个”。这时，队伍中段插进来一个人，理论上，新来者后面的所有人都要把纸条上的数字改大 1。但如果队长宣布：“从这一刻起，我以新来者所在的位置作为新的基准线，基准线后面的人不用改纸条，基准线前面的人也不用改，只有基准线本身做一次校正。”那么绝大多数人完全不需要动，排队体验自然就流畅了。标记表里维护的“基准线”，就是与 GapBuffer gap 对齐的那个标记表 gap。

4.3 节点结构定义

有序标记表的节点定义如下，用伪代码描述：

code复制struct MarkerNode {
    int delta;          // 相对于 gap 位置的偏移量增量
    bool leftBias;      // 绑定策略：true=左绑定，false=右绑定
    int length;         // 标记覆盖的长度（用于区间标记）
    void* data;         // 业务数据指针
    MarkerNode* prev;
    MarkerNode* next;
};

struct MarkerTable {
    MarkerNode* head;    // 表头哨兵
    MarkerNode* tail;    // 表尾哨兵
    MarkerNode* gapNode; // 与 GapBuffer gap 对齐的节点
    int gapOffset;       // 标记表 gap 的虚拟偏移量
};

不同标记的实际偏移量计算方式为：所有位于 gapNode 之前的节点，其偏移量由节点自身的 delta 累加得到；所有位于 gapNode 之后（含 gapNode）的节点，其偏移量需要加上 GapBuffer 的 gap 累积长度修正。具体计算时，编辑器会维护两个计数器——baseOffsetBeforeGap 和 baseOffsetAfterGap，这两个值随着 GapBuffer 的 gap 移动而更新。

可能在阅读伪代码时你会觉得有点绕，但实际上，只要把握住一个原则就能理解整个设计：GapBuffer 的 gap 移动时，只需要把标记表的 gap 同步过去；除了 gap 附近被“跨越”的节点，其余节点的 delta 值不变。 所有位于 gap 后方的节点的绝对偏移量，都等于“自身 delta 加上 gap 起始端到当前文档位置的偏移修正”。

这个延迟更新策略让标记表在大量编辑场景下几乎不需要回写。项目实测数据显示，一次普通的单字插入，标记表中需要实际修改的节点平均只有 1~3 个，与标记总数无关。

5. 核心操作的算法性能与实现细节

5.1 标记查询：O(1) 平均时间

查询某个逻辑位置上的标记，是编辑器高频操作之一，比如鼠标移动时检测位置附近是否有关键词高亮。传统做法是二分查找有序数组，复杂度 O(log n)。在这个算法里，由于引入了双计数器方案，查询可以做到平均 O(1)。

具体实现策略是维护一个“最近访问游标”。因为编辑器的事件流有很强的时序局部性——用户的光标移动、鼠标悬停、渲染线程的逐行扫描——每一次查询的位置与上一次查询位置通常非常接近。所以，在标记表中维护一个游标节点，每次查询时从游标开始向后或向前扫描若干个节点，找到目标位置即可。跨节点移动时，用 gap 同步后的增量做差即可快速判断。

实测效果：在 3 万个标记的文档中，随机逐行扫描时，单次标记查询平均耗时约 0.02 毫秒；而逐字符鼠标移动时的查询耗时更低，几乎可以忽略。这个结果依赖于标记表的有序性、gap 同步的准确性，以及游标局部性的有效性。

5.2 标记插入与删除：局部化操作

插入一个新标记时，首先根据目标位置找到插入点在标记表中的位置。找到后，按照绑定策略决定新节点的位置。如果是左绑定标记，新节点插入到目标位置对应节点的前面；如果是右绑定标记，插入到后面。插入操作本身是 O(1) 的链表操作，加上局部查找的开销。

删除标记时，通过节点指针直接摘除。如果删除的是区间标记（比如一对高亮标记），需要注意同时清理左端点和右端点两个节点，并且要保证在这两个节点之间有其他标记时也能正确处理。这里有一个容易犯的错误：如果区间内的标记也被删除了，链表会变成悬空状态，所以删除区间时需要先收集区间内的所有节点，再统一摘除。

我在项目中采用了一个辅助数据结构：一个简易的双向映射表。每个标记的 data 指针持有唯一的 ID，双向映射表负责 ID 到节点的快速查找。这样，业务层来删除标记时，不需要从头遍历链表找位置，直接根据 ID 拿到节点指针就可以操作。

5.3 批量分割与合并：应对一次多段编辑

真实输入场景往往不是单字符插入，而是 IME 组合、粘贴、删除选中区域等多字符操作。例如用户选中了 100 个字符然后删除，再粘贴 200 个字符。这个过程如果拆成两步依次处理，每一步都会触发一次标记表更新。如果标记表更新逻辑每次都能局部处理，那性能没有大问题；但如果文本跨度很大，就会牵动很多标记节点。

针对这种场景，算法中增加了一个“批量文本变更”的协议。批量操作的流程分为三个阶段：

1. 预处理阶段：收集所有受影响的标记节点，按位置排序。
2. 核心变更阶段：一次性执行 GapBuffer 的批量操作，同时把标记表中的 gap 移动到变更区间的开头。
3. 收尾阶段：对变更区间内的标记做一次净化的增量校正，而不是逐个处理文本变更的子事件。

这个协议让一次大范围的粘贴操作只需要一次标记表的重建，而不是多次增量更新。实测数据：在一个包含 5000 个标记的文档中，连续粘贴 200 个字符（跨 60 个标记），传统逐事件更新方案耗时约 15 毫秒，而批量协议耗时约 2 毫秒，性能提升接近 8 倍。

5.4 删除操作中的标记处理策略

删除文本时，标记的处理比插入要复杂——如果删除的文本恰好包含某个标记所在的位置，这个标记应该怎么办？不同的业务场景有不同的要求。

对于断点标记，如果断点所在的行被删除，通常断点本身也一并删除。对于高亮标记，如果高亮区间的部分内容被删除，一般希望高亮区间自动收缩。对于选区标记，如果选区内容被删除，选区起点和终点需要合并且可能整体移动。

这套算法里的处理策略是：标记的“左绑定/右绑定”属性，再辅以“覆盖删除策略”字段。覆盖删除策略有三种取值：

• DeleteWithRange：如果标记位置在删除范围内，则删除标记。
• MoveToRangeStart：如果标记位置在删除范围内，则把标记移动到删除范围的起始位置。
• MoveToRangeEnd：如果标记位置在删除范围内，则把标记移动到删除范围的结束位置。

选择哪种策略，完全取决于业务需求。这个设计让标记行为的可定制性很强，不同模块可以按需配置，而不需要修改核心算法。在项目里，高亮标记用 DeleteWithRange，选区标记用 MoveToRangeStart，折叠标记用 MoveToRangeEnd，各取所需。

6. 实战记录：一次完整的标记批量更新流程

6.1 场景设定

我以项目中最常见的一个场景为例，完整走一遍算法流程：用户在文档的第 1000 个字符处插入了一个换行符（\n）。此时文档里共有 2 万个标记。按照 GapBuffer 的特性，这个插入操作会把 gap 移动到位置 1000，然后写入换行符。

标记表层面，gap 同步触发。标记表会把 gapNode 定位到第 1000 个字符附近的标记节点上，然后执行“跨节点搬迁”操作。由于这次插入动作发生在标记表的 gap 区域附近，真正需要调整的节点只有紧邻 gap 的 1~2 个节点。其余节点的 delta 值完全不变。

6.2 实际操作步骤

步骤一：定位 GapBuffer 的 gap 位置。GapBuffer 维护 gapStart 和 gapEnd 两个指针。插入前，先判断目标位置与当前 gap 的位置关系，如果距离较远，需要先移动 gap，移动过程中会更新 baseOffsetBeforeGap 和 baseOffsetAfterGap 两个计数器。

步骤二：同步标记表 gap。遍历标记表，从当前 gapNode 出发，根据目标位置调整 gapNode。如果目标位置在 gapNode 的右侧，则沿 next 指针前进；如果在左侧，则沿 prev 指针后退。每跨过一个节点，更新一次计数器的值。

步骤三：写入字符到 GapBuffer。这一步的物理操作是把字符写入间隙位置，然后 gapStart 前进一位。

步骤四：更新受影响标记。根据文本变更的增量，对标记表 gap 附近的节点做最终的偏移量修正。对于单字符插入，这个修正量就是 1；对于多字符批量插入，修正量就是插入字符总数。

步骤五：触发标记事件。更新完成后，通知业务模块哪些标记发生了移动、哪些标记被删除，业务模块据此刷新渲染。

整个操作过程的数据流很清晰。如果用一个词概括这个设计，我觉得是“延迟校正”——把所有需要更新的节点先放到“待处理”状态，等 gap 同步完成后一次性做校正，而不是在插入的每个子步骤里都做一遍全局处理。

6.3 性能对比实测

项目完成后，我把新算法与传统的“全量遍历更新”方案做了一组对比测试。测试环境是一台中端配置的笔记本，文档大小为 10 万字符，标记数量分别取 1000、5000、10000、30000，在文档中间位置连续输入 100 个字符，统计全过程的标记更新耗时。

测试数据如下表所示：

可以看到，随着标记数量增长，传统方案的耗时线性上升，而新算法的耗时基本保持稳定。这说明新算法成功把标记更新与标记总量解耦，性能瓶颈从 O(n) 降到了近似 O(局部影响范围)。

这里需要说明的是，表中的性能提升倍率依赖于一个前提：连续输入的文本位置相对固定，gap 不会频繁大跨度跳跃。如果用户每次输入都跳到文档的完全不同的位置，那么 gap 同步的开销会变大，性能优势会有所缩小。即便如此，由于标记节点本身的更新是局部的，整体性能依然显著优于全量遍历。

7. 调试与优化：踩过的坑和排查技巧

7.1 覆盖率完整但标记错乱

项目进行到一半时，我遇到过一个问题：标记表在绝大多数场景下工作正常，但偶尔会出现某个高亮标记的位置发生偏移，偏移量恰好是 gap 的大小。这个问题非常隐蔽，因为它不是每次都出现，而是在特定的文本编辑序列下才会触发。

排查后定位到根因：GapBuffer 的 gap 在移动过程中，baseOffsetAfterGap 的更新时机出了问题。当 gap 向右移动时，baseOffsetBeforeGap 应该增加，baseOffsetAfterGap 应该减少；如果这两个计数器在某一过程中更新顺序反了，就会导致标记表中所有 gap 后方节点的偏移量全部错乱。

这个坑的教训是：涉及静态计数器的全局状态更新，必须严格按照顺序执行，并且在调试阶段给计数器加断言校验。后来我在代码里加入了一组运行时不变量检查——每次文本变更后，验证标记表中随机抽样的若干节点的偏移量是否正确。这样在测试阶段就能暴露问题，而不是让问题悄悄流到线上。

7.2 日志驱动的卡顿定位

“打字掉帧”问题最初的定位难度很大，因为性能问题不像功能问题那样有明确的错误信息。我的做法是给标记更新模块加了一套性能日志，输出每次文本变更时标记更新的处理节点数和耗时。日志数据很快揭示了问题——每次输入事件触发的标记更新居然遍历了所有标记，这个现象直接指向了“全量遍历”的实现缺陷。

加性能日志是个很实用的经验。建议在标记管理这类底层模块中，默认开启轻量级的耗时统计，比如每次操作记录“处理节点数”和“实际耗时”，这两个指标能快速判断性能是否符合预期，也方便在测试阶段做回归对比。

7.3 结构对称性的保持

有序标记表的双向链表结构相对脆弱，任何一次节点的摘除、移动、反转都需要保证前后节点的链接完整性。尤其在做区间删除时，很容易出现“只删除了左端点而右端点悬空”的情况。

我的经验是：每一类操作都写一个专门的“结构完整性校验函数”，在每次文本变更后调用。这个函数检查所有节点的 prev、next 指针是否成对匹配，检查链表总长度与业务层记录的数据条数是否一致，检查所有节点的位置是否严格递增。虽然这会增加少量运行开销，但在开发阶段非常有价值，能快速发现大部分并发或边界条件导致的问题。上线后可以把这个校验放到断言开关后面，降低运行时负担。

8. 与其他方案的对比：PieceTable 与红黑树

8.1 基于 PieceTable 的标记管理方案

PieceTable 是 VS Code 使用的文本表示方案，它的核心数据结构是由多个片段（piece）组成的链表，每个片段保存一段连续的文本。PieceTable 在文本变更时的行为与 GapBuffer 很不一样：插入新文本时，PieceTable 会在片段链表中插入一个新的片段节点，而不是移动大块的字符数据。

在 PieceTable 之上做标记管理，主流做法是给每个片段维护一个独立的标记区间，标记位置记录为“片段 ID + 片段内偏移”。这种方式非常适合大文本和并发操作，因为片段本身就是天然的局部性容器。但从实现复杂度来看，PieceTable 的方案比 GapBuffer 的方案要重不少，片段的分割、合并、缓存失效处理都需要额外的工作。

8.2 基于红黑树的标记管理方案

红黑树方案是另一种常见的标记管理实现，它把标记位置作为 key，存放在平衡二叉树中。红黑树的优势在于查询和插入的时间复杂度都是 O(log n)，适合需要频繁随机查询的场景。而且红黑树天然支持范围查询、前驱后继查找，功能非常丰富。

但红黑树方案有一个痛点：区间更新。当一个范围的标记全部需要偏移时，红黑树的标准实现需要逐个更新节点，除非引入额外的懒标记（lazy propagation）机制。懒标记的实现并不复杂，但改起来容易引入 bug，尤其在处理删除和分裂时。相比之下，GapBuffer 的标记表算法因为利用了 gap 的天然局部性，无需额外的懒标记机制就能实现类似的效果。

8.3 三者的适用场景对比

如果一个编辑器准备长期做超大文档支持和多人协作，PieceTable 可能更合适。但如果目标是做一个轻量、快速、代码结构清晰的编辑器，GapBuffer 加上本文这套标记管理算法，是一个非常实在的选择。我在项目中选了 GapBuffer 方案，综合考虑的是代码可维护性和与现有渲染引擎的配合——渲染引擎按行扫描时，标记表的顺序访问模式与游标局部性完美匹配，整体性能非常理想。

9. 扩展方向与个人心得

写完这套算法后，我还在项目的其他模块里复用了一些设计思路。比如，自动补全模块的“候选词位置缓存”和搜索模块的“匹配结果列表”，都采用了类似的延迟校正思想。这些场景的共同特点是：数据量动态变化、操作具有局部性、全局一致性要求不高，非常适合用带 gap 的链表来优化。

还有一个值得尝试的扩展方向是并发支持。当前实现是单线程模型，如果将来需要做多线程渲染或后台线程分析，可以在标记表之外再加一层读-写锁，或者用 copy-on-write 策略来保证快照的一致性。不过这里需要权衡——并发标记更新的复杂度会显著上升，如果不是硬需求，建议保持单线程。

关于调试，最后再给一个建议：文本编辑器的标记管理，一定要在测试阶段写好“随机编辑模糊测试”。生成一段随机文本，随机插入、删除、修改，每次操作后做全量的标记一致性校验。这个测试能覆盖绝大多数人手工测试覆盖不到的边界情况，是这类算法项目最有效的质量保障手段。我在项目中跑了这个模糊测试，一天之内就抓出了三个在手工测试里根本不会暴露的边界 bug。

这套算法在项目里的实际表现，比我最初预期的要好。上线后，用户反馈的“打字掉帧”问题基本消失，长文档编辑也顺滑了。回头看，最有价值的不是最终的代码，而是“延迟校正”这个设计思路——它让我意识到，很多性能问题的解药，往往在于把“操作前更新”改为“操作后校正”，问题就迎刃而解了。