黄泓毅做文本编辑器底层的编辑器内核时，大部分人首先接触到的方案就是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+l