1. 两个月的重构不是拍脑袋是卡到忍无可忍1.1 老版本的真实状态一个 2MB 文件把整个应用拖垮我接手这个 Markdown 编辑器的时候它其实已经上线跑了大半年功能不缺该有的都有代码高亮、实时预览、表格支持、导出 HTML 和 PDF甚至在用户群里还有一批死忠。真正让人崩溃的是性能。当时群里最经典的一句话是想用你们的编辑器写长文档先准备好一杯咖啡。 这话听着像玩笑但你真去打开一个 2MB 的 markdown 文件就知道一点都不夸张——文件打开后界面白屏好几秒然后风扇开始狂转鼠标还能动但整个窗口像是被什么咬住了一样拖拽都费劲。2MB 是什么概念纯文本 markdown 的话大约是 45 到 50 万个字符按平均每行 40 个字符估算大概有 1.2 到 1.5 万行。这个体量放到今天任何一个正经编辑器里都应该是秒开的可老版本就是扛不住。我自己做了一轮基准复现用同一个包含大量代码块、表格、多级列表和引用块的 markdown 文档一次次冷启动打开测出来平均耗时 5.8 秒期间 UI 完全无响应。在文档里每敲一个字符输入延迟大约在 300 到 500 毫秒也就是说你连续输入一行字屏幕上的光标会滞后小半拍。滚动就更痛苦了不是卡顿是直接漂移滚动一下整个文档要重新绘制一遍肉眼能看到明显的白屏闪烁。用户反馈集中在三个场景第一打开大文件第二在长文档里搜索替换第三同时打开两个大文档做对比。这三个场景本质上都指向同一个问题——这个编辑器在处理大宗文本时存在某个被放大了的计算瓶颈。刚开始我们以为是硬件问题后来发现用户用 i7 处理器和 16GB 内存也一样卡那就不是硬件能救的了。1.2 目标不是推翻重来而是把三条主链路打穿重构之前团队内部其实是吵过一轮的。有一半人主张直接用 Electron 上成熟的 Monaco 或者 CodeMirror换内核省事另一半人觉得插件、自定义语法、现有主题体系都绑定在自研内核上全换掉等于产品重做风险太大。最后我们选择了一条折中路保留自研内核但推翻内部的核心架构用两个月时间重写解析和渲染两条链路。为什么敢这么干因为我们确认过功能代码本身没有大问题问题出在数据从文件进来之后到界面画出来这一段的处理方式上。这次重构只给三个月实际上压缩到两个月所以范围必须收得很死。我们定了三条硬指标冷启动打开一个 2MB 标准 markdown 文档耗时不超过 1.2 秒目标 1 秒文档内连续输入时字符到屏幕的延迟不超过 50 毫秒长文档滚动不掉帧滚动过程不出现全量重绘的白屏。同时明确不做的事情也很重要不做新的主题系统不改插件 API不动命令面板。所有跟编辑体验无关的边缘功能一律冻结。这样做的目的只有一个——让两个月的窗口期全部花在性能主链路上不被周边问题稀释。现在回头看这个范围隔离是整个项目能按期交付的关键。很多重构项目死在顺手改一下顺便优化下这种心态里改着改着就变成了无限扩张。我们当时立了一条规矩任何与三项目标无关的代码 merge request直接打回不讨论。1.3 重构组的内部结构三个人三条线一个公共测试集这次重构实际投入的是三个半人我负责整体架构和解析器另一位同事负责渲染层和虚拟滚动还有一位前端工程师负责衔接层、事件系统和自动化测试。测试集是整个重构的地基我们找了几十份公开的 markdown 文档从几 KB 到 4MB 不等覆盖了 README、技术博客、API 文档、长篇小说甚至爬下来的网页转 markdown 文件。每份文档都配上统一的基准脚本统计打开耗时、内存峰值、滚动帧率、输入延迟四类数据。在动第一行业务代码之前我们先花了一周做性能剖析。这里我要多说一句这周看起来没有产出但恰恰是最值的。因为只有先把瓶颈定位到具体函数和具体算法上后面每一个改动才有依据。否则凭感觉优化优化最后大概率是瞎忙。具体怎么定位下一节展开讲。2. 卡顿的根子在解析链路不在渲染本身2.1 Performance 面板里三个扎眼的数字我调试性能有个习惯先用 Chrome DevTools Performance 面板录一段完整的冷启动过程从文件读入到界面首帧出来然后把火焰图导出来逐段看。老版本打开 2MB 文件录完放大一看时间基本被三块吃掉第一块是文件读取和预处理占大概 300 毫秒左右这里面包括把文件内容按行拆分成数组、做 UTF-8 转码、简单语法扫描。第二块是 markdown 解析也就是把文本转成内部 AST这一下直接干掉 3.2 秒是整个流程里最夸张的耗时点。第三块是渲染把 AST 转成 DOM 并挂载到页面又花掉 1.8 秒。剩下的一些小头尾加起来几百毫秒。这三个数字一出来问题就清楚了解析占了整体耗时的 55%渲染占了 31%。打开文件慢主要就是这两条链路的锅。但更让我意外的是老版本在输入时也一样卡而输入过程理论上只需要解析变化的那一小块内容。我继续录输入事件发现每次按键代码居然会重建整棵 AST然后重新渲染整个文档。也就是说你在第 5000 行敲一个字前面 4999 行也得跟着重新解析一遍。这个设计非常不合理但你要说它错吧它也不是没有道理——很多编辑器为了正确性都采用全量重建这条路因为增量更新太难做了容易在各种奇葩 markdown 语法组合上翻车。可全量重建的复杂度是 O(n)n 是文档总行数文档一大线性增长也扛不住。2.2 三个叠加的瓶颈全量扫描、同步解析、DOM 全量重建打开慢和输入卡表面上看是两个问题其实是同一批底层机制的三个叠加效应。第一个是全量扫描。每次渲染前编辑器会把整个文档内容重新过一遍不是只过变化区域。这个在文档小的时候无所谓比如一个 20KB 的 README全量扫描也就几毫秒。但当文档到 2MB字符量 50 万级别全量扫描的代价就开始显现。更糟糕的是老版本解析的过程不是一次性的它内部有多层处理先是按行分词然后构建块级结构再对行内做标记解析比如加粗、链接、行内代码。每一层都要遍历一次全文等于一个 2MB 文件要被来回扫好几遍。第二个是同步解析。JavaScript 是单线程的老版本的解析器是纯同步代码从第一行跑到最后一行中间不交还控制权。这意味着浏览器主线程被完全占死UI 渲染、事件响应全部排队。2MB 文档同步解析耗掉 3 秒多这三秒里整个应用就是假死状态。用户感知到的白屏、拖不动都是因为主线程被解析器堵死了。第三个是 DOM 全量重建。解析完成后渲染层会为每一个文本块、标题、代码块、表格创建对应的 DOM 节点然后一次性替换掉旧节点。2MB 文档粗略估算有上万个块光 DOM 节点就是十几万个。浏览器面对十几万个节点的插入和样式计算即使什么都不做也要花个一两秒。更致命的是这种全量替换会破坏页面滚动位置所以老版本里打开大文件之后滚动条位置经常重置到顶部体验非常糟。这三个瓶颈叠在一起才造成2MB 文档约 1 秒打开听起来像天方夜谭。但实际上如果我们能做到只解析必要部分、异步分片执行、渲染时按需创建节点哪怕 4MB 文档也能控制在 1 秒内。2.3 为什么 2MB 恰好是那道分水岭很多用户不太理解为什么 200KB 的文档还行一到 2MB 就崩。这背后其实是一个复杂度台阶问题。当文档小于某个阈值比如 200KB全量解析需要的时间大约 300 毫秒左右虽然也能感觉到轻微卡顿但还能忍。文档一旦涨到 2MB需要解析的字符数翻了 10 倍但解析器内部有些操作的复杂度是超线性的比如临时字符串的拼接、嵌套数据结构的递归、DOM 节点的样式重算这些都不是严格 O(n)而是接近 O(n log n) 甚至更差。所以文档从 200KB 涨到 2MB耗时不是涨 10 倍而是从 300 毫秒涨到 3 秒多直接越过用户心理承受线。另一方面2MB 也是很多真实场景的最长最长场景。一本长篇技术文档的 markdown 源码通常也就 300KB 到 800KB一个大型开源项目的 README 加上 docs 目录合并偶尔能到 1MB 出头。2MB 已经属于极端情况。我当时跟团队说如果我们能把 2MB 压到 1 秒那么日常 90% 的文档都会是秒开感知性能会提升得非常明显。所以这个目标不是一个空洞的 KPI它是一条有实际意义的性能分界线。2.4 用 1 秒反推技术方案哪些必须做哪些可以不碰定了 1 秒的目标之后我们把预算拆了一下。按 2MB、50 万字符算理想流程是这样的文件读取和预处理 100 毫秒以内增量解析首屏需要的那部分 200 毫秒以内渲染首屏可见区域 200 毫秒以内其余时间留给调度、初始化、后台陆续解析不可见区域。总预算控制在 700 到 800 毫秒留出 200 毫秒余量。这个拆分看起来粗暴但它让我们明确了三件事第一解析器绝不能同步一次性跑完整个文件第二渲染绝不能一次性创建全部 DOM第三需要一种增量调度机制让文档在后台继续解析而不是等全部解析完成再显示。方案定下来三个关键词异步分片、增量解析、可视区渲染。后面所有代码都是围绕这三个词展开的。中间的取舍也很直接——用户打开文件第一眼看到的应该是能看、能滚、能输至于文档尾部还没解析完完全可以在用户翻到那里之前悄悄补完。这也是很多现代编辑器能在超大文件上保持流畅的核心思路。想清楚这一点架构改造的方向就清晰了。3. 重写解析器从全量构建到增量分片3.1 解析链路的新架构fast scan、块级 AST、延迟任务老版本解析器是一口气把整个文件变成一棵完整 AST再交给渲染层。新的架构把它拆成了三层。第一层叫 fast scan也叫快速扫描。它的任务只有一个把原始文本按行切分成有类型的块比如标题、段落、代码围栏、列表项、引用块。这一层不解析行内语法不做嵌套结构只是用正则和状态机按顺序过一遍速度非常快。实测 2MB 文档的 fast scan 大概 80 毫秒出头。扫描产物是一个扁平数组每个元素对应一个块记录它的行号范围、块类型、层级深度和原始文本。这个阶段几乎不产生新对象只复用原始字符串的 subrange所以内存开销很低。第二层是块级 AST 构建。在 fast scan 得到的块数组基础上按照 markdown 的块级规则把嵌套关系组装起来比如列表里嵌套子列表、引用块里包含代码块和标题。这一层同样不做行内解析。组装结果是标准的块级树每个节点关联它在源文件中的行号范围。块级 AST 的好处是它比全 AST 轻得多数百万行文档的块树节点数通常只有行数的几分之一而且构建快、便于做局部的子树替换。第三层是懒解析任务队列。行内标记比如**加粗**、[链接](url)、行内代码全部推迟到一个按需调度的任务队列里。渲染器只对当前可见的块发起行内解析请求不可见块保持未解析状态。当用户滚动到某个未解析的块附近滚动调度的空闲回调会立刻把它解析出来这个延迟非常低用户几乎感知不到。新架构还有一个核心特性解析结果缓存。每个块保存一个内容哈希只要源码没变解析结果就直接复用。对于大文档来说用户通常只修改某个局部区域其余上千个块的解析结果都是有效的完全不需要重新计算。3.2 增量更新的脏区域算法不是重跑全文而是打补丁增量更新是这个架构里最核心也最容易出错的部分。我把它设计成一个从编辑位置向外扩散的脏区域算法触发点很简单用户输入、删除、粘贴、undo/redo都会在文档模型里产生一个变更事件包含变更起始行号、删除行数、插入行数以及变更后的文本内容。收到变更事件后编辑器不会对整个文件重新 fast scan而是先把变更点对应的原始快加入一个重解析队列。然后执行一个循环从变更行开始解析一段范围内的行看它能否与之前的块结构正确衔接。如果解析结果在边界处与现有块树匹配不上就把范围向上下扩展直到边界对齐为止。这个扩散最多进行有限轮次超过阈值后就退化为从最近的稳定锚点开始重新解析。锚点通常是文档开头、某级标题、顶层列表项或者代码围栏的开始行它们天然具有打断上下文依赖的能力从锚点重新开始解析能保证正确性。举个例子用户在列表中间按回车新增了一个空行这个变更不会影响列表前面的任何内容脏区域最多覆盖当前列表项到下一个顶层标题之间的范围。在这个区域重新 fast scan 和构建块树再把结果替换到原有块数组中整个操作可能只花几毫秒。输入性能从原来 300 多毫秒的延迟直接降到了个位数毫秒。下面是脏区域扩散的简化实现思路用 TypeScript 描述核心逻辑type ChangeEvent { line: number; oldLineCount: number; newLineCount: number; text: string; }; function applyChangeToBlockTree(root: BlockNode, change: ChangeEvent) { let start change.line; let end change.line change.newLineCount; const block locateBlockAtLine(root, start); // 尝试用最小范围的源码重建这段块结构 let rebuilt scanAndBuildBlock(start, end); while (!canMerge(root, start, end, rebuilt)) { // 边界不匹配向上下各扩展若干行 start Math.max(0, start - EXTEND_LINES); end Math.min(totalLines, end EXTEND_LINES); rebuilt scanAndBuildBlock(start, end); if (extendCount MAX_EXTEND) { // 退化为从最近的稳定锚点开始重建 const anchor locateAnchorAbove(root, start); rebuilt scanAndBuildBlock(anchor, end); break; } } replaceBlockRange(root, block, rebuilt); root.rebuildLineIndex(); }这个算法最大的好处是90% 的编辑操作都只需要重建几十行范围内的块结构真正的扩展到全文档几乎不会触发。代价就是实现时必须仔细处理块与块之间的上下文依赖比如列表嵌套是否闭合、引用块的续行规则、代码围栏是否处于打开状态这些边界问题稍不留神就出错。我们后来在 6.1 节会详细聊踩过的坑。3.3 行内解析的按需调度和结果复用行内标记解析和块级解析是彻底解耦的。块级解析完成后文档已经可以渲染成一个半成品能看到标题、段落、列表和代码块的基本轮廓但行内字体加粗、斜体、链接样式还没有。这些样式由行内解析器按需补齐。调度器是一个简单的高性价比任务队列当主线程空闲时用 requestIdleCallback从当前滚动位置上下各取一个一定数量的 block执行行内解析如果用户在滚动就优先处理滚向方向的块。实测中文档滚动到从未访问过的区域时从触发滚动到行内样式完整显示的间隔大约 20 到 40 毫秒基本感知不到。为了避免同一个块被重复解析每个块维护一个inlineState取值是unparsed、parsing、parsed三种。内容哈希是判断是否过期的关键——只有当块内容发生变化时状态才会重置为unparsed。这套缓存机制在长文档来回滚动、编辑后撤销恢复的场景下收益特别明显因为同一块通常会被反复访问缓存命中能省掉大量重复计算。3.4 多行语法跨块这些边界必须单独设计新架构的增量更新最大的难点集中在一个逻辑块实际上横跨多个物理行而且它的开始可能在变更区域之外。典型的有三种情况。第一种是代码围栏。文档里某个位置出现了开头后面 100 行都是代码内容直到遇到另一个才闭合。如果用户在代码块中间修改了某一行增量更新不能只把这一行当普通段落处理它必须知道当前处于代码围栏内部并且整块代码文本都需要作为纯文本保存不能解析里面的 markdown 标记。我们的 fast scan 在发现时会记录状态如果变更点的起始位置已经在一个未闭合的围栏里就强制把变更区域的起点拉回到这个围栏的起始行然后再重建。第二种是引用块和列表的续行规则。markdown 里一行 引用内容后面跟一个没有前缀的普通行在标准实现中通常被视为引用块的延续。列表项同理缩进的下一行即使没有-前缀也可能属于上一个列表项。这意味着块边界的判定不能只看单行文本还要参考上下文的缩进和前缀。我们在脏区域算法里处理这个问题的办法是每次重建都会带上区域首部之前的一到两行作为上下文行这些行不参与更新只用于判定边界是否连续。实际用下来这种带上文的方式比只看区域内行的正确率高得多。第三种是表格。markdown 表格表头、分隔行、数据行的依赖关系非常强分隔行一旦缺失或者列数不对表格结构就会整段变质。我们单独把表格识别做成一个表格块fast scan 遇到表格起始行后会贪婪地往后吃所有表格行直到遇到空行或非表格行。增量更新如果落在表格内部必须整块重建表格块不能只更新表格中的某一行。这些边界在最初几周测试里疯狂暴露我们最后把整套边界用例整理成了三个测试文件接近 400 个测试点。可以说增量解析的工程量一大半都在这些看起来不起眼的边界处理上。4. 编辑器视图层改造虚拟滚动和按需渲染4.1 为什么打开文件的大头在 DOM 装配解析器改造完成后打开文件的时间从 3.2 秒降到了大概 300 毫秒左右但整体耗时仍然有 2 秒多。继续用 Performance 面板看剩下的瓶颈几乎全在 DOM 装配上。老版本的做法是把 AST 一次性转换成 HTML 字符串然后设置成一个巨大容器元素的 innerHTML。听起来很高效对不对实际上不是。首先2MB 的文档转换成 HTML字符串本身就超过 5MBinnerHTML 解析这么长的字符串浏览器要经过 HTML 解析器、DOM 树构建、CSS 样式计算、布局、绘制等一系列过程。即使 innerHTML 的底层是 C 实现的数据量摆在那里最终也要落成几十万个 DOM 节点。其次渲染之后的样式回调、事件委托注册、代码高亮等后处理同样要遍历所有节点。这个DOM 爆炸才是打开文件耗时的主要来源。所以视图层的方向很明确不要让所有节点一次性出现在 DOM 里。基于这个思路我们做了两件事——虚拟滚动 可视区内渲染。这两件事相辅相成共同把 DOM 总量限制在几百个节点内。4.2 虚拟滚动实现要点行高缓存、缓冲区、占位符虚拟滚动的原理不复杂不管文档总高度多大实际上用户的屏幕只能看到一部分内容我们只需要渲染视口内以及上下缓冲区的块其余区域用空白的占位元素把滚动条高度撑起来。听起来简单落地的时候有几个细节特别容易踩。首先是总高度的计算。如果一个文档有 8000 个块每个块的渲染高度各不相同直接说总高度 8000 * 平均高度那是不准确的会导致滚动条位置错乱。我们的方案是给每个块维护一个渲染高度默认给一个估计值实际渲染完成后用真实高度回写。同时维护一个前缀高度索引便于从滚动偏移量快速定位当前应该显示哪些块。这个索引用类似跳表的结构两层就够查找复杂度是 O(log n)滚动时定位当前首行只要几微秒。其次是缓冲区的设置。我们做了一个双向缓冲视口上方 3 屏、下方 3 屏之内的块会提前渲染出来超出这个范围就销毁。这样快速滚动时新进入视口的块不会因为刚要渲染而闪白屏。缓冲区的大小要根据块的渲染成本调整。对代码高亮这种成本比较高的块缓冲区还可以再加大。实测中3 屏缓冲区在普通鼠标滚轮的滚动速度下完全够用但如果是触控板快速甩动偶尔会看到短暂的空白后来我们把缓冲区改成 5 屏才彻底消掉。虚拟滚动和系统原生滚动条也有一层配合关系。我们把整个编辑区包裹在一个普通 div 里overflow: auto内部放一个高度等于文档总高的占位容器再用绝对定位把当前块列表渲染在对应的位置上。这种绝对定位按偏移量摆放的方式比每次滚动都重排容器内容要稳定得多也是社区里主流虚拟滚动库的做法。我们最开始是自己手写了一个简单的版本后来发现边界情况太多干脆基于成熟的虚拟列表逻辑改造省了不少事。4.3 预览区和编辑区的双屏联动优化这个编辑器有双栏模式左边编辑原文本右边实时预览渲染后的 markdown。老版本的预览区在超大文档下比编辑区更卡因为它是完全独立于编辑器视图的又一套 DOM而且每次输入都要全量重新渲染。重构后我们把预览区也接入同一套增量解析结果编辑区产生的块树是源数据预览区本质上只是同一棵块树的另一种视图。预览区和编辑区共用一个滚动位置通过一个联动状态同步。当用户滚动编辑区预览区会自动滚到对应的块的位置反之亦然。这个联动的计算依赖块级 AST 中的行号映射——编辑区滚动到第 2000 行预览区就找到与这个行号最近的块节点并滚到该块预览视图对应的高度。这样拖动滚动条时两边节奏是完全同步的。预览区的渲染也做了按需处理只有接近视口的块才真正解析行内语法并渲染成 HTML其他块用轻量的占位文本替代。这个优化让双栏模式的大文档体验从卡成幻灯片提升到跟单栏模式差不多流畅。用户测试的时候甚至有人问我们是不是把预览改成单页静态渲染了其实背后就是复用了解析和虚拟渲染两套机制。4.4 输入延迟的处理合并更新和宏任务调度前面提到老版本输入延迟 300 到 500 毫秒。重构后这一块的原理是输入不直接触发同步渲染。keydown 事件进来后先把文本变更应用到文档模型然后立即请求一个宏任务requestAnimationFrame来处理当前帧的增量解析和局部渲染。在同一帧里如果用户连续输入了多个字符中文输入法更是如此这些变更会被合并成一次增量更新只做一次解析和渲染。这个合并机制非常重要因为中文输入法会在很短时间内触发十几个 composition 事件如果每个事件都做完整解析那还是卡。实际调优时我们保留了光标闪烁优先的原则输入的第一优先级是让光标位置和当前已输入字符尽可能快地显示出来其他不可见区域的解析全部让路。打个比方输入延迟优化做的是少干活而不是把活干得更快。只有真正减少了每一帧的工作量才能在高频输入下维持 60fps 的顺滑感。5. 2MB 文档的实际压测数据与调参过程5.1 重构前后的四项核心指标对比两个月重构完成进入验收阶段。我们拿同一批测试文档跑基准脚本重点看四项数据冷启动打开耗时、滚动帧率、输入延迟、内存峰值。下面这张表是其中一份 2.1MB 测试文档的结果文档结构包含 4200 个段落、280 个代码块、110 个表格和超过 1500 个列表项。指标老版本新版本优化幅度冷启动打开耗时5.8 秒1.1 秒约 5.3 倍连续滚动平均帧率18 fps58 fps约 3.2 倍输入到出字延迟P95420 毫秒38 毫秒约 11 倍峰值内存占用打开后稳定860 MB410 MB降低 52%第一批数据出来后1 秒打开还没有完全达标1.1 秒离 1.0 秒只差一点但就差那么点。我们在 Profile 里又揪出一个隐藏开销冷启动初始渲染时虚拟列表一次性预渲染了上下 5 屏的缓冲区这个操作在文档刚打开时就触发了 6 屏块的行内解析、代码高亮和样式计算占了大概 150 毫秒。优化方式是把冷启动的缓冲区改成先 1 屏空闲后再补到 5 屏首屏速度明显提升。最终打开耗时稳定在 1.0 到 1.1 秒之间不同文档稍有波动目标基本达成。真正让我觉得这次重构没白做的是滚动表现——58 fps 基本就是贴着 60fps 上限在跑而且连续滚动 5 分钟没有内存持续上涨说明节点销毁和复用机制是健康的。5.2 调参过程哪些参数值得抠哪些纯属心理安慰这个月我调整最频繁的几个参数记录一下供后来人参考。第一是虚拟缓冲区的屏数。我们最终设置在 5 屏但这个值不是越大越好。缓冲区太大会导致初始渲染变重内存也跟着涨太小又会在快速滚动时露白。取舍的关键是看你的目标用户主要用什么输入设备。如果办公场景以鼠标滚轮为主3 屏就够触控板用户多就要到 5 到 7 屏。我们选择 5 屏是两者兼顾的结果。第二是行内解析任务队列的单次处理量。我们设定每帧最多处理 20 个块的行内解析。如果一次处理太多当前帧就会超时处理太少滚动到新区域时会感觉样式跳出。这个值跟机器性能关系不大主要受块的平均复杂度影响。代码块密集的文档20 个块可能耗尽预算纯文本段落为主的文档一次处理 50 个都没问题。最后我们做了一个动态预算根据当前一帧的实际耗时自动调整下一帧的处理量让帧率保持在 55fps 以上。第三是脏区域扩展的步长。我们最开始设置为上下各扩展 20 行实测在某些嵌套场景下还是要循环好几轮。后来改成了先按 50 行扩展如果还不匹配就跳转到最近的锚点整体重试次数少了结果反而更快。这个参数不建议调得太小因为边界不匹配往往意味着结构性问题靠小步扩展很难救回来。也调过一些后来发现没用的参数比如把行内解析任务改为用 Web Worker。听起来应该更快但在我们的架构里行内解析需要频繁访问块树和样式上下文结构化克隆的开销反而把收益吃掉了。最后 Worker 只用于 fast scan 这种内存连续、上下文少的重计算。这里也给我们一个教训不是所有异步化都有收益要测量不要拍脑袋。5.3 用户视角的验收长文档工作流还顺吗指标归指标用户真正关心的是用起来顺不顺。我们找了 5 个之前反馈最激烈的重度用户做内测每人发了一份接近 2MB 的真实长篇文档让他们完成三个任务打开文档后快速定位到第 1500 行、在全文范围搜索一个关键词并替换、直接拉到文末追加一段 500 字的内容。结果反馈比我们预期还好三个人说打开秒开两个人说打开之后稍微等一下下就能编辑滚动顺畅搜索替换也没有出现卡顿。唯一被吐槽的点是文末追加内容时如果文档还没解析完增量更新偶尔会和后台解析任务抢 CPU导致追加后短暂掉一两帧。这个问题后来通过一个变更优先于后台解析的调度策略解决了有编辑事件进来后台循环立刻让位。这些反馈让我意识到性能优化的价值不是跑分好看而是让用户不再被工具打断思路。文档编辑器作为一个工具最好的状态就是感觉不到它在工作。这次的压测数据证明了方向是对的但也暴露了很多只有在真实场景里才会出现的细节问题。6. 这次重构踩过的坑和后来人值得注意的地方6.1 增量更新最深的坑多行 block 被拦腰截断增量更新这块我们踩翻车最惨的一次是在列表嵌套场景。当时测试集里有一份文档第 200 行是一个嵌套了 3 层的列表项这个列表项内部还带一个引用块和一段代码。我们只修改了列表项中间某个词按预期应该只重建这个列表项所在的块但实际跑起来重建后的列表项会和后面的内容完全脱节整个文档从那个位置开始乱套。排查了很久才发现问题fast scan 阶段我们误把被缩进的下一行当作了一个新块而实际上它仍然是上一个列表项的子内容。脏区域扩展时又只带了区域上方两行作为上下文不足以让扫描器确定这里其实还在列表项内部。最终修复办法就是上文提到的带上文行方案而且上下文行数不是固定的要根据当前块的类型动态调整。比如列表项需要带上整个列表头引用块要带上前面的引用前缀。这个修复让我们的边界测试用例从 200 多个一下子涨到 400 多个。这个坑给我们的教训是markdown 的块级结构不是一个行与行相互独立的格式它有很强的上下文依赖。凡是想做增量解析的编辑器都必须先回答一个哲学问题一个块到底是从哪里开始、到哪里结束这个边界搞不清楚后面全白搭。6.2 事件节流引发的光标跳跃视觉 Bug新版本刚换上虚拟滚动的时候内部测试出现了一个诡异问题输入时如果光标正好在视口边缘按下空格键整行文字会闪烁一下然后光标跳到奇怪的位置看起来像键盘漂移。一开始怀疑是文档模型算错了行号查了一圈才发现是虚拟滚动加事件节流惹的祸。原因是这样的我们给滚动事件做了节流每 100 毫秒最多处理一次滚动位置同步。当用户输入文字导致当前块高度变化比如某一行文字换行块变高了文档总高度和块偏移都会变。这时候如果滚动位置没有及时同步光标所在的行会被虚拟列表判断为在视口外从而被销毁然后下一帧又检测到光标位置把它重新渲染出来。一销毁一重建视觉上就是闪烁和跳动。修复并不复杂在文档高度变化事件里立刻重新计算当前块的偏移量并把滚动位置锁定到光标所在行上面不让它掉出视口。这个逻辑必须同步执行不能放在节流事件里。类似的坑还有输入法 composition 期间触发滚动同步也会造成光标跳动最终我们把光标跟随事件优先级调到最高所有其他调度都要让路。6.3 兼容性和回滚策略重构期间不敢删的老代码两个月重构的过程中我们一直保留着老版本完整代码通过特性开关切换新旧内核。每次合并新代码到主分支都先交给自动化测试跑一轮再让团队内部在旧内核和新内核之间来回切换对比。这个并行双轨策略让我们没有任何一个晚上是重构到一半无法工作的状态。不过保留老代码也有副作用两套渲染逻辑并存很容易被人不小心改乱。我们的规矩是新代码一律放到新目录里老代码目录冻结除了修安全问题不允许任何改动。这个做法虽然增加了代码量但保证了任何时刻都有一条可回退的路。最后切换上线的时间点我们还专门压了一版旧的 tag用于线上紧急回滚。如果你也打算重构类似的基础组件我强烈建议保留一条明确的回滚通道。性能优化的风险不在于做不出来而在于做到一半项目状态不可控。能随时回到旧版本团队的心理压力会小很多反而更容易按时交付。6.4 重构完成后的长期收益不只是打开快了这次重构结束后我们内部开玩笑说这个编辑器从能用变成了好用。但我个人总结的长期收益其实有三层。第一层是用户体验层面的。2MB 文档从 5.8 秒到 1 秒看似只是数字变化但它直接改变用户对产品的定位认知——原来只敢在小文档上用现在敢把长篇技术文档和知识库都放进来使用场景一下子从便签扩展到了写作工作台。第二层是架构层面的。解析和渲染解耦后后面加功能变得容易很多。比如后来加的自定义代码块渲染、大纲面板、文档概览图都是直接复用块级 AST 和滚动定位系统不需要再在渲染链路里动刀。第三层是性能审计常态化。这次重构建立了一整套基准测试脚本和自动化告警机制后续每次发版都会跑一遍性能回归。我们立了一个规矩任何 MR 如果导致 2MB 文档打开耗时增加超过 100 毫秒必须说明原因并提供优化方案否则不允许合入。基于这次的经验性能问题不会再等到爆发才处理而是纳入每天的开发流程里。最后再说一个针对 Markdown 编辑器场景的小技巧性能优化一定要用真实文档压测不要自己手写一个几万行的 lorem ipsum 就完事。真实文档里的列表嵌套、代码块、表格、图片引用、极长 URL、中文排版每一种都会激活不同的代码路径。我们最终的测试集里甚至放了一篇从 PDF 转出来的小说里面夹杂了大量空行和半角全角混排这类脏数据才最能暴露问题。如果你正在为长期被吐槽卡顿的文档工具做重构不妨先收集十份用户投诉里最典型的文档再开始动手。性能问题的解法往往就藏在最细碎的真实文件里。