黄泓毅做文本编辑器底层的编辑器内核时，大部分人首先接触到的方案就是GapBuffer。老实说，GapBuffer的结构本身并不难，难的是围绕它展开的一套"标记管理"逻辑。一个文本编辑器只要支持光标、选区、书签、语法高亮区间、诊断信息位置，就逃不开标记位置的维护问题。如果只用朴素数组做buffer，插入删除后所有后续文本的坐标都要改；而GapBuffer把文本分成左右两段，gap本身又会造成逻辑位置和物理位置的错位，标记漂移问题反而更容易踩坑。这篇东西我想从一个实现者的角度，把GapBuffer下如何设计一套高效的标记管理算法讲透。
我没有把这个问题当成一个单纯的数据结构作业来写，而是站在"真的要把编辑器做到可用"的立场上。适合两种人看：一种是自己写简易编辑器、Markdown预览器、代码渲染组件的人；另一种是对算法有兴趣，想弄明白为什么仅仅保存一个"文档偏移量"远远不够的人。下面讲到的规则和坑，都是从实际代码里掉进去又爬出来的经验。
1. GapBuffer的坐标模型：先说清楚逻辑位置与物理位置
GapBuffer这个概念其实很直观。它不像普通数组那样把所有字符紧紧挤在一起，而是在缓冲区中间留一段空白区域，这个区域叫gap。gap左侧的字符顺序保持不变，gap右侧的字符在内存里其实是连续存放的，只是与左侧字符之间隔了一段空位。这样设计的原因很实际：编辑器最常见的操作是光标附近插入字符，而插入字符只需要占用gap空间，不需要把后面的文本整片右移。
很多人在这一步就产生了一个误解，觉得只要把文件内容存在gap两侧，然后维护一个gapStart和gapLength，性能就足够了。真相是，GapBuffer真正麻烦的地方在于"位置的表达"。文档里第9个字符，这是逻辑位置；但它在内存中实际偏移可能是10或10+gapLength，因为要跨过gap，这是物理位置。二者只有在gapStart的左侧才恰好相等，一旦位置落在gap右侧，物理索引就需要加上gap长度才能换算。
这就是我把这个模型单独拿出来讲的原因。标记系统需要先选定一套坐标。如果直接保存物理索引，当gap移动时，所有落在右侧的标记物理值全部失效，除非给每个标记额外记录一段"位于gap左侧还是右侧"的信息，还得在每次move gap后重算，这是非常原始的方案，维护成本会冲垮GapBuffer带来的收益。更合适的方式是让上层标记只感知逻辑位置，也就是文档中从0到length的连续坐标。
之前调过一段代码，有人在insert事件里直接拿buffer物理下标遍历字符串，光标还没移动几步，高亮区间就错乱得没法看。后来把标记全部改成保存"文档偏移量"并在每次文本变更后统一更新，整个系统才稳定下来。原因并不复杂：物理位置是GapBuffer的内部实现细节，而标记是文档内容的持久语义，二者必须解耦。
1.1 双栈式GapBuffer的底层行为
我实现过的一个稳定版本是用两个vector模拟左右栈，左侧栈正向存放光标之前的字符，右侧栈反向存放光标之后的字符。假设文档内容是"abcdefg"，光标在c和d之间，那么左侧栈内容为"abc"，右侧栈从栈顶到栈底依次是"d""e""f""g"，也就是说底层存储顺序是"gfed"。编辑器看到的是完整字符串，底层则是左右两段分离的结构。
光标向右移动一位时，真实发生的动作是从右侧栈顶端弹出字符'd'，压入左侧栈变成"abcd"，gapStart因此增加1。光标向左移动一位时，则从左侧栈弹出'c'，推入右侧栈顶端，gapStart减少1。整个过程只有常数次push/pop，不涉及memmove整段数据，这正是它适合大文件连续输入的原因。插入字符时，文本被push进左侧栈，逻辑长度增加；删除字符时，如果光标在中间，光标前删就是pop左侧栈，光标后删就是pop右侧栈。
这里有一个容易被忽略的点：文件内容可能通过"在某处插入一大段文本"的方式修改，而不是只由逐字输入驱动。比如一次性粘贴5000字符，若当前光标不在某个段的边界，就要先把光标移到插入点，再把文本写入左侧栈。实际操作中，insert接口通常统一成"把gap移动到插入点，然后将文本追加到gap左侧"。如果你把这一步拆开看，会更容易理解后面为什么标记更新可以单独抽出做。
1.2 逻辑坐标换算的两个公式
为了后面讲标记更新不产生歧义，这里先给出坐标换算公式。文档逻辑长度等于左侧文本长度加上右侧文本长度，注意不把gap空间算进去。若gap长度为G，gapStart表示左侧文本的物理终点，也是逻辑文档中光标的位置，那么逻辑位置p映射到物理位置时遵循：
- 当p <= gapStart时，物理索引就是p本身
- 当p > gapStart时，物理索引是p + G
这里的G不是固定值。插入和删除会让gap长度动态变化，移动光标会让gapStart来回变化。标记系统如果每次访问都做这种换算，不仅慢，还容易出错。更好的办法是在每次文本变更结束后，让所有标记的位置值直接指向新的逻辑坐标，这样标记单元内部不再需要感知gap的存在，gap只是buffer在文本变更那一刻的内部状态。后续渲染层拿标记位置访问文本时，只做一次换算即可。这种设计把"变更时更新"和"按位置读取"分离开，是后面整个标记管理算法的基础。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 标记漂移的根源：一次编辑动作到底改了什么
如果你拿一个数组存字符串，在位置5插入一个字符，那么原本索引5及之后的所有字符都向右挪1格，这个挪动会精准映射到所有标记上。GapBuffer因为gap的移动，会让人误以为"我插入时某些文本没有真正移动，所以标记可能不需要全部更新"。这个判断是错的。
逻辑文档并不关心物理移动，只关心字符序列的排列。在位置p插入长度为len的文本后，从新文本之后的第一个字符开始，所有字符的文档位置都加len。也就是说，任何标记，只要它的逻辑位置在"插入文本末尾之后"，就必须向右偏移len。如果它恰好指向插入点本身，需要看这个标记是左粘滞还是右粘滞。左粘滞的标记留在插入前的位置，右粘滞的标记跟着插入文本的末尾走。
删除动作也类似。删除从p到p+len的字符后，被删字符原本占据的一系列位置全部塌缩到p。原来位置大于p+len的标记向左移动len；原来位置落在删除区间内部、包括恰好等于p+len的标记，全部收缩到p点。这个"全部收缩到p"的规则容易让人皱眉，尤其是做选区高亮的时候，一个选区的终点在删除区间的右边界，删除后它到底应该在哪里？结论是：在文本模型层面，它就是p。选区是否保留完全由UI层决定，而不是由文本模型逆推。
2.1 一次插入动作对三种标记的影响
假设当前文档长度是20，插入点在位置8，插入长度3。标记A位置为5，标记B位置为8，标记C位置为12。这时候A不受影响，还在位置5；C需要变成15；B就要看策略了。如果B是书签，它可能希望留在原地，因为书签代表"这个位置节点"，插入内容后它仍然在原字附近；如果B是光标，它绝对希望跟随输入，变成11，不然每敲一个字光标就往后跳，根本没法用。
所以标记不是单一的数值，它至少需要携带一个stickiness属性。我习惯叫它gravity，左重力或者右重力。插入发生在标记位置p时：
- 左重力：标记保持p
- 右重力：标记变成p + len
这个规则非常小，但它直接决定了编辑器的体验。大多数编辑器都把光标和选区右端点设成右重力，选区左端点和一些锚点类标记设成左重力。如果你不给标记区分重力，就会出现"输入时HTML标签高亮范围越缩越小"或者"字符选区向前漏字"的怪现象。这也是很多号称自研编辑器的项目被使用者骂手感不对的重要原因。
2.2 删除动作的区间塌缩模型
删除区间[p, p+len)时，受影响标记可以分成三类：
- 位置 < p：完全不受影响
- 位置在[p, p+len]范围内：统统映射到p
- 位置 > p+len：位置减去len
这个模型比我一开始设想的简化了很多。我最初的实现版本试图细分删除区间的内部标记，想让左端点和右端点各自保留在删除区间边界附近。但实际用起来发现，对于"某个字符被删除了，位置到底是定义在字符左边还是右边"这种问题，区分越细，使用的逻辑越复杂，收益却几乎为零。
真正需要区分的是被删除区间内部本来就有的一堆书签、断点或搜索高亮。比如用户全选了某段内容按下Delete，如果这段内容里有10个断点标记，这些断点随文本一起消失是合理的。所以在标记系统层面，我通常会为每个标记提供一个onRemoved回调或者一个removeWhenDeleted标志。删除发生且区间塌缩后，如果标记决定留在原处，它会被放回p点，并进入"所有标记叠加在同一位置"的状态；如果它认为自己已经失效，就把它从标记集合里移除。上层的UI看到标记集合少了某个断点，自然会更新对应状态。
3. 设计标记数据结构：从裸数组到有序容器
很多初学GapBuffer的人会直接把标记放进一个哈希表，key是位置，value是标记ID。这样查某个位置的标记确实快，但哈希表丢失了位置之间的顺序关系。标记变更时，你需要遍历所有key判断哪些受影响，哈希遍历不仅慢而且无序，处理过程会产生大量不可预期的跳跃。我建议不要用哈希表做全局标记索引，至少不要作为唯一存储。
一种很实用的方式是按位置排序的数组或平衡树。我用的是vector保持内部按pos升序排列。因为标记数量通常不会特别大，几百到几千个很常见，vector在这量级下表现极好，缓存命中率远高于链表。每次变更后虽然可能移动一部分标记，但并没有改变这些标记彼此之间的相对顺序，所以不需要对整个数组重新排序。
标记对象本身至少需要这些字段：id、pos、gravity、tag类型。tag类型能区分光标、选区端点、书签、诊断线。真正在编辑器里光标和选区是高频对象，通常会单独给一个exclusive指针，不放进通用标记容器，避免每次输入都要在通用标记数组里找光标的位置。其他标记才走统一容器。
3.1 两层容器结构的核心接口
我把整个标记模块拆成两层。上层是从标记ID到标记对象的索引map，用于UI按ID精确访问；下层是排序数组，专门服务于位置扫描和更新。两层都持有同一个标记对象指针，避免同一数据复制两份。添加标记时，按pos插入到排序数组中，并在map里登记。删除标记时，先在排序数组里找到对象，再把map中条目清掉。
核心位置操作接口有三个：
- markerAt(pos)：返回该位置或该位置之后最近的标记
- markersInRange(start, end)：返回区间内的全部标记
- updateAfterEdit(editType, start, length)：编辑完成后统一修正所有标记
这三个接口不需要关心GapBuffer内部到底怎么存储文本。每次编辑完成，text core只要通知标记模块"我在哪个逻辑位置插入多少字符"或"删除了哪一段"，标记模块就能推进自身状态。这层隔离让标记容器可以独立测试，甚至可以先不接GapBuffer，用普通字符串模拟变更也能跑。
3.2 位置排序数组最重要的特性：更新后仍然有序
插入长度为len的文本后，所有受影响标记要么变成原来的pos，要么变成pos+len，后者整体是一个向右平移的动作。排序数组原本是按pos升序排列的，平移后，所有被移动的标记彼此之间相对顺序仍然不变。删除后向左平移len，顺序也同样不变。
这个特性看似不起眼，却是整套算法高效的支点。它让我不需要在每次编辑后调用sort，不需要维护复杂的平衡树旋转逻辑，只需要定位第一个受影响的位置，然后从那里开始顺序处理，处理完毕后数组天然重新有序。因为gap移动并不改变逻辑位置，标记模块甚至完全不需要感知moveGap事件，只有当真正插入文本或删除文本时才触发update。
4. 标记更新算法：核心规则与复杂度分析
现在进入正题。假设标记容器是一个按pos升序的vector，我定义一个updateAfterEdit的函数处理所有标记更新。插入操作的伪代码如下：
code复制void afterInsert(size_t pos, size_t len) {
// lower_bound返回第一个pos >= 目标值的标记
auto it = lower_bound(markers.begin(), markers.end(), pos,
[](const Marker& m, size_t v){ return m.pos < v; });
for (; it != markers.end(); ++it) {
if (it->pos > pos || it->gravity == Gravity::Right) {
it->pos += len;
}
}
}
为什么这里不直接让所有pos等于pos的右重力标记加len，pos大于pos的标记也加len，而是用了一个if？原因在于位置完全等于pos且gravity等于Left的标记，它应当贴在左侧文本末尾，插入操作不影响它。位置大于pos的所有标记都必须加len，因为它们都在插入文本的后方。如果这段代码写成无脑从it向后全部加len，左重力且恰好位于插入点的标记就会被错误推动。
删除操作复杂一些。我现在采用的实现大致是：
code复制void afterErase(size_t pos, size_t len) {
auto first = lower_bound(markers.begin(), markers.end(), pos,
[](const Marker& m, size_t v){ return m.pos < v; });
auto last = upper_bound(first, markers.end(), pos + len,
[](size_t v, const Marker& m){ return v < m.pos; });
// 区间 [first, last) 内的标记塌缩到 pos
for (auto it = first; it != last; ++it) {
it->pos = pos;
if (it->removeWhenDeleted) markForRemoval(it->id);
}
// 删除区间右边界之后的标记向左平移 len
for (auto it = last; it != markers.end(); ++it) {
it->pos -= len;
}
// 统一清理需要删除的标记
}
删除后，原位置为pos的标记会被设置为pos，原位置为pos+len的标记也会被设置为pos，两者在删除后的文档里实际上叠在了同一位置。这是符合逻辑位置塌缩模型的。但有一点需要特别留意：如果删除区间覆盖了整个文件，也就是pos=0且len等于原文档长度，那么所有标记都落入被删除区间，全部成为pos=0的空位置标记。UI层在下一次渲染时能不能接受所有断点堆在文件开头，是必须提前设计的。
4.1 复杂度到底是多少
这个更新过程的时间复杂度取决于受影响的标记数量，而不是总标记数量。插入时，从lower_bound命中的位置开始到末尾，都是受影响后缀。假设总标记数是M，需要移动后缀中的K个标记，插入更新就是O(log M + K)。
删除分两段：先处理被删除区间内部的标记，再平移右边界之后的标记。右边界之后的标记数量可能很多，比如删除位置在第100行，而整个文件有成千上万个书签都在后面，那么这段平移操作可能就是O(M)。这种场景其实无法避免，因为每个标记的pos都必须改变。但如果编辑操作发生在文件末尾，代价就极小。
这也是GapBuffer的天然优势之一。绝大多数交互式编辑都发生在光标附近，而光标往往不在文件最开头，所以几乎每次插入都要移动光标后方的大量标记。如果标记数量上千，这看起来仍然有点恐怖。实际跑下来却问题不大，因为普通标记数量最多几十上百个，一次变更统一操作几十个整数是非常快的。如果真的要支持几十万个标记，比如逐字符做语法高亮，那就不应该用这套逐标记绝对值方案，应该去做分段存储，这个放到后面展开。
4.2 处理区间查询时的二分查找细节
markersInRange(start, end)接口在两个地方比较关键：一是选区变化时UI要拿到这个范围内的标记，二是语法高亮要渲染某个可见区域的所有标记。实现时用两个二分查找就能完成。第一个lower_bound找第一个pos>=start的标记，第二个upper_bound找第一个pos>end的标记，两者的迭代区间就是结果。
这里要小心upper_bound的比较方向。C++里默认upper_bound接受值和迭代器比较，我习惯显式写lambda避免混淆。区间查询出来的标记不用排序，因为底层本来就是有序的。如果你做的是行级渲染，用行号过滤一遍即可。由于标记位置是逻辑坐标，如果要把它换算成屏幕行，还得通过行表索引一次，这个不在标记模块负责范围内。
5. 边界情况大扫除：选区的头尾、跨gap和空文档
代码写多了会发现，算法的主体框架往往一天就能搭好，真正折磨人的全是边界情况。这个标记管理算法也不例外。我先列举一组我实际遇到过的边界场景，每个都踩出过bug。
第一个是选区跨gap的问题。GapBuffer移动后，gap可能正好落在当前选区内部，比如光标选中了从左侧栈末尾到右侧栈开头的一大段文本。因为左侧栈和右侧栈物理上不连续，遍历选区内容时必须走一遍"先向左取到gapStart，再从右侧栈反向取字符，最后再拼起来"的逻辑。但标记系统本身不该管这些，标记只保存startPos和endPos两个逻辑位置。gap怎么分布是文本存储层的事，选区高亮层只需要按逻辑位置区间去找文本。这里如果你的标记遍历逻辑里去读buffer物理下标，就会出问题。
第二个是删除范围与被删除文本的重叠处理。前面说过，删除后所有[p, p+len]区间内的标记会塌缩到p，但我没有提到两个标记本来都在p+len、一个左重力一个右重力的情况。塌缩后它们仍然都在p，但它们在排序数组里的先后顺序可能会变。因为原位置p+len的所有标记原本排在原位置p的标记后面，删除后它们全部被改成p，排序数组必须允许相等pos存在，而且更新后仍然保持稳定。如果把标记容器当成set去重，这些标记会被错误合并。所以标记容器的唯一约束是"非严格升序"，也就是当前元素允许等于下一个元素。
第三个是空文档中插入首个字符。此时p=0，文档长度为0，所有标记都堆在位置0。插入一个字符后，如果某标记是右重力，它的目标位置变成1。如果它是左重力，它仍然在0。这会让原本叠在一起的标记裂开，一部分在0，一部分在1。这类场景看起来很简单，却最容易让人写出"insert后所有标记pos都加len"的错误逻辑，最终把所有标记都推到文末。
另一个很容易出问题的边界是删除长度为0的操作，或者called undo但不改变文本的隐藏操作。标记更新函数必须先检查len是否为0，直接返回。之前的代码就因为在某条undo路径上没有过滤空删除，导致删除逻辑执行了下标越界，折腾了好几天才定位到问题。防御性编程在这里值得多写一行。
5.1 选区端点的成对约束
把选区作为两个独立标记分别更新会产生一个隐蔽的毛病：删除发生在选区内时，startPos塌缩到p，endPos也塌缩到p，选区变成一个空选区。在某些文本编辑场景里，用户希望删除选中内容后选区自动折叠成光标位置，这种结果没问题。但在语法括号匹配场景里，如果选中了一段包含括号内全部内容的代码，删除后通常希望光标停在被删除起始位置，而不是停在整个区域的最前面。
其实还有更深一层的问题：如果startPos和endPos是两个独立标记且没有关联关系，那么只要受重力策略影响，它们的相对顺序可能会反转。比如startPos=5是右重力，endPos=5也是右重力，插入3个字符，二者都变成8，仍然满足start<=end。但如果startPos=5是右重力而endPos=10是左重力，在位置5插入3个字符后start变成8，end保持在10，仍然正常。再比如在位置6插入3个字符，start保持在5，end还是10，也正常。相对顺序反转通常不会出现，因为同一位置只能有一个相同起始点，但为了保险，validateSelection函数在每次更新后检查start<=end是一个值得做的契约检查。
选区的更新规则我更偏向于不用通用标记更新，而是单独写一个selectionManger。这样选区端点可以作为一个整体被调用，不在通用容器里占位置。一方面通用标记数量因此减少，另一方面选区有特殊的"删除后光标落点"逻辑，单列出来更清晰。比如删除某个选区文本，通用标记容器会把右端点缩到p，但编辑器实际可能想保留右端点在下一次光标位置附近。文本模型和UI交互的关系不能混为一谈，这是我在项目里反复重构后得出的结论。
5.2 被删除标记的回调时机
删除时处理那些随文本一起失效的标记，要小心不要在遍历容器的过程中直接erase元素，否则迭代器会失效。我的做法是分两遍：第一遍遍历要删除的标记，打个标记，并把它从ID索引表移除；第二遍统一erase所有失效标记。erase时vector可能会发生整体移动，但由于这些标记往往都在同一连续区间，利用vector的erase可以一次性删除区间，把多次搬移合并成一次。
如果某个标记代表一种UI装饰，比如搜索高亮，当它对应的文本被删掉时，UI可能需要收到通知去清理高亮层。这个通知最好在标记真正从容器删除后触发，而不是在更新过程中触发，因为UI回调里可能还会继续调用标记模块，递归进入更新流程会带来状态混乱。用一个deferred callback队列累积事件，等本次更新彻底结束再向外广播，是比较稳妥的做法。
6. 上万级标记的优化思路：分段、区间偏移和分策略
如果只是给编辑器做光标和书签，前面的算法完全够用。但很多人会想，GapBuffer本身的定位是处理超大文档，如果标记数量也飙升到十万级，这套逐标记更新会不会崩？答案是会，尤其在语法高亮或全文诊断这类场景下。诊断标记可能覆盖每个字符，插入一个字符让全文所有诊断位置向右移一格，如果每个诊断都改一遍，灾难性事件就发生了。
解决思路不是去优化遍历循环，而是改变"每个标记必须实时保存绝对pos"的设计。常见的优化方向有几条。
第一种是给标记分组，不同类型标记用不同容器。比如光标组单独维护，bookmark组用普通数组，语法高亮组用分块结构。这样每次编辑时，高频少量标记快速更新，海量低频标记走延迟或部分更新。语法高亮其实不需要对每个token都精确维护位置，更常见的做法是行级失效：某一行的文本变了，就重新对这个范围进行高亮分析，而不是把原来的token标记整体平移。
第二种是区间偏移预计算。对于大量具有相同偏移模式的标记，可以在标记上维护一个"单调偏移量"，而不是实时更新实际pos。查询标记位置时再把逻辑偏移叠加起来。既然插入操作总是让编辑点之后的所有标记右移，你可以维护一个全局Fenwick树，记录文档位置点的累计偏移，每个标记只保存初始位置和ID。文档变更时只做range update，标记的当前位置通过query获得。这种方式查询次数少的时候很高效，但如果你需要频繁遍历所有标记，query的工作量又会回来。
我做实际项目时最终选了第三条路：不做全局百万标记的实时绝对位置维护，而是把文本变更事件按行派发给分块的语义层。比如行0到100之间的内容被替换，发布一个rangeChanged事件，这个范围内的语法高亮可以直接整块重算，范围外的行级索引不动。编辑器的核心标记容器只维护真正"必须跨行稳定存在"的少量标记，例如断点、书签和光标。这样一百万行的文档也能保持编辑响应不卡。
6.1 用编辑批次减少标记更新次数
还有一个非常实用的优化手段，是不让文本存储层每次只捅给标记模块一个字符的变更。如果你连续输入100个字符，插入100次，标记模块就会循环操作100次，每次都从头定位受影响后缀。低效是其次，最严重的是一方面真实应用中还要跟随滚动条和高亮重绘，每个字符都触发一次处理很容易出现闪烁。
常见的做法是引入一个事务或批次概念。输入法组合期间，从compositionStart到compositionEnd合并成一次文本替换。粘贴时，整个粘贴Paste也合并为一次大插入。撤销重做更是天然的大批次，甚至可能横跨多次插入删除。标记模块应该接收一次"整段替换"事件，比如replace(start, oldLen, newText)，而不是拆成delete加insert两次。整段替换内部可以一次性完成删除塌缩和插入平移，避免标记被先向左拉再向右推，产生无谓的中间态。
我之前记录过一次bug：选区高亮在undo回退后错位了两个字符。根源就是undo被拆成了erase然后insert，每次操作独立更新标记，中间态把选区端点错误地夹到了删除区间的右边界。改成统一的replace原子操作后，问题立刻消失。这个经验的价值有时候比具体算法还大。
6.2 标记与GapBuffer频率差异的处理
理论上，如果用户持续把光标从文件末尾移到开头，GapBuffer会执行几百次moveGap，每次都会搬字符，但标记完全不需要更新。因为moveGap只改变gap的位置，不改变文档逻辑内容。可现实里的编辑器框架，却常常把moveGap操作也发成一个"selection change"或者"marker change"事件，导致UI层拿着标记位置重新查询文本。
解决方案是在文本存储层单独区分bufferChanged与selectionChanged两个通知。只有真正改变了文档逻辑内容的事件才触发标记更新，gap移动产生的通知只能影响光标所在行和可视区域的渲染。如果框架层没法区分二者，就在GapBuffer内部给textRevision加版本号，标记更新只在revision递增时发生，否则直接跳过。这样即使moveGap被频繁触发，标记模块也不会陷入无意义循环。
7. 实际项目中的结构与测试：一个最小可运行实现
如果要把前面内容落成一个最小实现，我建议这样拆模块。TextBuffer里只处理左右栈和gap的移动，不持有任何标记对象，对外暴露一个ChangeListener接口。MarkerManager负责维护有序标记容器，接收onBeforeChange和onAfterChange回调。onBeforeChange用于记录哪些标记会在删除时被移除并通知UI，onAfterChange按本文第4节的算法推进所有标记位置。
代码骨架可以长这样：
code复制struct Marker {
int id;
int pos;
bool rightGravity;
int tag;
};
class MarkerManager {
std::vector<Marker> markers;
void afterInsert(int pos, int len);
void afterErase(int pos, int len);
void eraseMarkersInRange(int start, int end);
int markerAt(int pos);
};
class GapBufferText {
std::vector<char> left;
std::vector<char> right;
int gapSize() const { return capacity - left.size() - right.size(); }
void moveGapTo(int pos);
void insertAt(int pos, const std::string& text);
void eraseAt(int pos, int len);
};
GapBufferText里维护一个可变的预留容量。随着左侧文本不断push，预留区会逐渐耗尽。当剩余空间不够下一次大块插入时，需要resize底层向量并重新调整gap位置。如果你用的两个独立vector，每个vector有自己的capacity，那么所谓gap实际上是左侧vector和右侧vector之间预留的"未使用空间"，不一定是连续内存。这在语义上稍微偏离了原始GapBuffer的"连续空位"模型，但对编辑逻辑影响不大。
构造一个测试用例时，我会把文本设定为100000个字符，然后在随机位置插入和删除，每次操作后强制断言所有标记位置对应的字符内容与预期一致。比如先记录位置1000的字符是'x'，在它前面插入字符串后，再验证标记指向的仍是'x'。这类断言比单纯检查marker数量更可靠，因为位置错乱经常只在特定字符内容下才暴露。
7.1 实测中出现的高频问题
我试着在本地环境跑过几组数据，虽然机器不同结果会有差异，但现象很稳定。当标记数量小于5000时，每次插入更新花费的时间几乎无法被感知；当标记数量到50000且全部需要平移时，单次操作能明显看到延迟。这个分界点促使我放弃了对通用标记容器做极端性能优化，转而把50000个重量级标记拆分到各语义层。
还有一个高频问题是用lower_bound查找时，很多实现会把删除区间边界后的标记误判成被删除。比如删除区间是[10, 20)，一个标记在位置20，它实际不属于被删除文本，应该在删除后向左平移10变成10。如果lower_bound写成了找pos>=10，upper_bound找pos>20，那么该标记会被排除在被删除区间之外，接下来在右平移循环里被正确减10。这没问题。但如果误把条件写成pos>=20，它就会被当成被删除区间的成员，错误地塌缩到10，同时后续又不会减10，导致结果刚好对不上的概率存在。这也是这类算法难以通过粗糙测试发现的原因，很多测试没覆盖到边界恰好等于区间端点的情况。
7.2 后续可以扩展的方向
如果你希望继续深挖，可以从GapBuffer出发对比PieceTable。PieceTable天然按片段存储文本，标记如果挂在片段上，文本变更只需要对片段进行切分和替换，某些标记可以自动跟随所属片段移动，不需要像GapBuffer一样全局扫描。它丢失的是连续输入的cache locality。两者结合也会产生一种混合方案：文本用GapBuffer，超大量连续标记用PieceTable式块索引存位置引用。编辑器领域没有银弹，关键还是弄清每种结构的优势区间。
我自己在维护这套标记系统的过程中最大的体会是：数据结构往往只是入场券，真正定义编辑器手感的是那些贴着语义边界的标记策略。Mark左重力右重力选择、删除塌缩行为、批量原子处理，每一条看似微小，最后都会以"用户的输入光标跑到奇怪地方"或"选区高亮闪一下"的形式反馈到使用体验上。下次你在任何一个编辑器里选中一段代码、按下回车，再观察光标和高亮是否如预期跟随，背后多半就是这么一套不起眼却要反复打磨的规则在工作。