最近我把手上那个 Markdown 编辑器项目完整重写了一遍前后花了差不多两个月。最初让我下决心的场景很朴素同事给我丢来一个 2 MB 左右的 Markdown 文件里面塞了大量代码块、表格和从网页上直接复制下来的长文本我用自己那版编辑器打开鼠标要先转圈两三秒才能挪动滚动起来像在看慢放视频。那一刻我意识到问题不在文件大而在编辑器本身的架构一直在偷懒。这版重写完成后同样那份 2.4 MB 的文档冷启动打开到能编辑基本稳定在 1 秒左右。不是开了什么秘密加速而是把之前“全量渲染 全量解析 全量高亮”的思路整个推倒换成“按需加载 分块解析 虚拟滚动”。这篇就记录一下我在这两个月里踩过的坑、做过的取舍以及最后落地的核心方案。这内容适合谁看一类是像我一样在做本地 Markdown 工具、笔记软件、文档站后台的开发者另一类是准备对自己的编辑器项目做性能重构、但还没想清楚从哪里下刀的人。我会把关键步骤拆开讲也会把性能调试时最常遇到的问题直接列出来。1. 重构前的真实状态2 MB 文档为什么会卡成 PPT1.1 先搞清楚 2 MB 的 Markdown 到底是什么概念很多人一听到“2 MB 文档”就以为只有几十万字。实际上 Markdown 文件的体积往往被代码块、Base64 图片、大表格和大量换行撑起来。我那份测试文件看起来很夸张全文拆成行为 2.7 万行里面有 138 个代码块有 47 个超过 20 列的大表格还有一段从网页复制的“超长无换行文本”单行长度到了 42 万个字符。这种文件在真实场景里并不罕见。数据仓库的 README、技术文档导出包、抓取下来的网页存档、论文笔记合集都很容易长成这样。很多 Markdown 编辑器在 200 KB 以内表现不错一到这个量级就原形毕露本质原因是它们把“渲染一屏内容”和“渲染整个文件”当成了同一件事。1.2 旧架构的三个致命设计我原来的编辑器走的是典型的小项目快速迭代路线读文件后按行拆成一个数组每次内容变化就重新跑一遍 markdown 解析然后把整个 HTML 字符串innerHTML塞进预览区编辑区的代码高亮也是整篇刷。这套逻辑在 100 KB 时没什么问题到了 2 MB 就会连续踩中三个坑。第一DOM 节点爆炸。2.7 万行全部渲染成文本行和代码 span浏览器里大概会出现 40 万个节点。任何一个属性变化都可能引发全局重排光是把光标从第 100 行移到第 1000 行浏览器就得处理中间 900 行的布局。第二Markdown 解析全量同步执行。用 markdown-it 解析 2.4 MB 文本在普通笔记本上大概要 600 到 800 毫秒这还没算 GFM 表格、代码块高亮这些扩展。期间主线程被占死用户点哪里都没反应。第三无差别的实时预览。旧的预览机制是“内容一变就全量重新渲染”。输入一个字符整份文档的 HTML 全部重建预览区从头滚动到尾部。这种用户体验在文件小的时候只是有点浪费文件一大就成了灾难。1.3 重写还是打补丁我当时做过一个很现实的评估旧代码并不是没救比如我可以加防抖可以把解析放到 setTimeout 里可以把预览改成懒加载。但这些方案都只是在给一个结构不合理的系统止血。真正的问题是“全量渲染”和“按需渲染”之间隔着一条架构鸿沟靠几个补丁跨不过去。所以我决定重构。范围限定在编辑器底层三个模块文档模型、解析链路、渲染层。外层 UI、快捷键、主题这些尽量保留避免一次改动面过大。重构最重要的原则不是“删掉重写”而是“先确定边界再把新架构填进去”。2. 重构核心理念一切渲染都必须按需进行2.1 编辑器内核选择为什么我放弃了 contenteditableMarkdown 编辑器的主编辑区一般有两条路用textarea加自定义高亮层或者用contenteditable。老版本我用的就是 contenteditable因为它实现“所见即所得”最省事。可一旦文档变大contenteditable的不可控性就非常让人头疼浏览器会为每个子节点维护复杂的可编辑状态灵活但指令复杂节点稍微一多输入响应就容易明显变慢。这次我选择了 CodeMirror 6 作为编辑区内核。理由有三个它的行渲染本身自带虚拟化视口外的行不会出现在 DOM 里它的状态管理是数据驱动的方便我结合自定义解析结果它支持把文档按行做精细处理长行高亮也能切成片段来做。当然CodeMirror 6 不是唯一的答案。Monaco 也能达到类似效果但它一个编辑器内核就很大而且对移动端的适配更重。我的项目还要跑在浏览器里所以 CodeMirror 6 的体量更合适。注意不要把 CodeMirror 6 当成“用法简单”的组件。它的架构和 React/Vue 的响应式理念不太一样需要花点时间理解 View、State、Transaction 之间的关系。我第一周基本都在看文档和写最小验证代码。2.2 文档模型从“行数组”升级为“行索引 块索引”重构后的文档模型不再直接保存一个纯文本数组而是分两层第一层是行索引。所有文本按行切分每一行记录行号、长度、起始偏移量这层主要服务编辑和光标定位。第二层是块索引。Markdown 解析后得到块级结构比如标题、段落、列表、代码块、表格、引用块。每块记录自己的起始行、结束行、类型、状态标志。编辑器需要预览时只需要把当前视口碰到的块渲染出来。这样做的核心价值是编辑区一个字符发生变化不需要重新索引全部内容。我们可以把变化范围投影到块索引里只标记受影响的块为 dirty。预览渲染时拿到这些 dirty 块单独重新解析、重新渲染。绝大多数普通编辑操作都只影响一个段落或者一个代码块全量解析的开销因此完全被规避了。2.3 Web Worker把 Markdown 解析从主线程请出去我做的第二个关键决定是所有 Markdown 解析逻辑都放进 Web Worker。解析不是轻量操作即使单块解析只需要 2 到 3 毫秒当用户快速输入时主线程也不该承担这份负担。Work 线程里跑的是 markdown-it 加 GFM 扩展解析结果不直接返回 HTML 字符串而是返回 AST抽象语法树的快照。主线程拿到 AST 后再把其中涉及到的块级节点映射到虚拟滚动列表里。这样做的好处是 AST 可以复用同一段内容没变化时不需要重新解析。为了避免 Worker 和主线程之间频繁通信我做了两层缓冲编辑区在用户停顿 150 毫秒后才发送解析请求同一时间只允许一个解析任务在跑新任务进来时会丢弃排队中的旧任务只保留最新一次请求。也就是说无论用户输入速度多快Worker 最多比最新状态慢一个版本。3. 核心实现细节从打开文件到秒开3.1 文件读取与初始化流程先说说 2 MB 文件从磁盘到可编辑状态之间发生了什么。老代码是file.text()一把梭文件多大主线程就要分配多大内存并且一次性切割成行数组。2 MB 文本可能只有 2 万到 3 万行实际分层速度并不慢真正的瓶颈在后续渲染。新流程是这样用File.slice()把文件分片读取或者直接用file.text()读取但如果文件超过 5 MB则优先用流式读取。读取完成后把文本交给 Worker 做全量解析。Worker 返回解析结果和一个基础行索引。主线程先算出视口对应的起始行只渲染行索引里属于视口的那一小段文本首屏大概只需要 30 到 50 行。代码高亮、预览区和文档概览等额外 UI 全部在首屏渲染完成后异步构建。关键细节是首屏渲染期间编辑器内核必须直接可用。如果用户在第 1 秒内输入了字符我们不等待全量解析结果而是先让 CodeMirror 接管纯文本输入。解析结果到达后用增量方式合并进去。这样就能保证打开文档后不是“假可用”而是真正可输入。3.2 虚拟滚动与代码高亮的成本控制虚拟滚动是所有大文档编辑器的底线。如果文档有 2.7 万行浏览器视口只能显示 40 行左右那么剩下的 26600 行就不该有 DOM 节点。CodeMirror 6 自带视图层会处理行虚拟化但在自定义预览区、目录树、文档结构面板里我仍然要自己实现一个列表虚拟化。我写了一个轻量虚拟列表组件接收块索引数组然后根据滚动位置计算哪些块进入视口。每个块渲染时记录下自己的像素高度下一次滚动时就能直接用来定位不需要重新测量。这样预览区即使渲染整个 2 MB 文档实际 DOM 节点数也一直保持在一屏范围。代码高亮也要控制成本。常规做法是在渲染每行代码时同步调用 highlight.js这在 2 MB 文档里会变成很昂贵的操作。我的方案是代码块只有在进入视口时才高亮离开视口的代码块先保留纯文本并标记为“待回收”。为了不让用户看到代码块“先白后高亮”的闪烁我把高亮计算放到了 requestIdleCallback 里。如果浏览器当前不太忙就多算几个可视区域外的代码块如果用户正在快速滚动就暂停高亮优先保证滚动流畅。3.3 长行与超大表格的处理重构的另一个重点是超长行。普通的 Markdown 文本不会太长但有的人会从网页复制一整段排版混乱的内容或者把一段 Base64 编码贴在文档中间。这些行如果直接交给编辑器不仅渲染慢光标移动也会异常卡顿。解决办法是“行切片高亮”。对于超过 2000 字符的行我在渲染前先按字符切块只对当前视口可见的范围做高亮计算。光标移动到下一段时再切换高亮区间。这个过程对用户是无感的但明显降低了编辑器对大文本行的压力。表格是最容易拖垮 Markdown 编辑器的东西。一个大表格如果有 30 列、2000 行按普通 DOM Table 渲染浏览器很难扛住。我的重构方案是预览区内的大表格被拆成“表头 当前行”两块当用户滚动时虚拟列表只渲染进入视口的行和对应表头并把表格列宽度做成按第一行内容估算的固定值。这样表格在视觉上完整但 DOM 结构比原来的全量 Table 小一个数量级。3.4 预览区如何做到不拖累编辑一般 Markdown 编辑器都有分屏预览我的也不意外。以前预览和编辑是同步的每输入一个字符都重新渲染预览。重构后我把预览分成三层状态已确认内容用户停止输入超过 300 毫秒后这层内容才会刷新。编辑中的内容显示一个隐藏的标记不实时刷新只在浏览器空闲时更新。视口外内容完全冻结不渲染。这样用户编辑长文档时预览区不会频繁跳动也不会在输入法选词过程中反复闪烁。唯一的小代价是“实时预览”变成了“接近实时的预览”但换来的是整个页面不再卡顿。实际使用下来绝大多数人根本感知不到这个 260 毫秒的隐藏延迟。预览区还做了一件事图片延迟加载。Markdown 文档里经常内嵌大量图片甚至有人会把图片转成 Base64 塞在 MD 文件里。我在渲染预览块时默认不加载图片只有图片进入视口且临近加载状态时才生成src。对那种 10 MB 级别的 Base64 图像这个策略能避免打开文档时直接吃掉全部内存。4. 性能调试、实测数据与常见问题4.1 我用的三样性能工具重构期间我几乎每一版都会跑一遍性能对比。最容易出结果的工具是这三个第一Chrome DevTools 的 Performance 面板。它能看到主线程的任务占用时间尤其适合寻找“哪个函数占用超过 1 秒”之类的问题。我在第二届优化中就用它发现代码高亮占了全量渲染里百分之四十七以上的时间。第二Memory 面板。Markdown 编辑器最容易出现内存只涨不降的问题。我用它做了大量“打开大文件、滚动到底、再滚回顶部”的重复操作观察节点数和堆内存是否被持续回收。虚拟滚动组件首先要保证内存曲线不会再顶上去。第三一个简单的 shell 基准脚本。我准备了几份不同大小不同结构的 Markdown 文件用 Puppeteer 拉起浏览器统计从加载完成到首屏渲染完成的时间、滚动过程的帧率、输入 100 个字符的平均响应时间。每次改完代码都跑一遍结果存成同一个基线防止回退。4.2 从卡顿到秒开的具体数据这里给一组真实记录。测试机器是一台普通的 Windows 笔记本浏览器为 Chrome 稳定版测试文件 2.4 MB2.7 万行。旧版本的数据是打开到可编辑大约 2.8 秒首次滚动响应约 1.2 秒持续输入时输入法从选字到上屏平均延迟 480 毫秒代码预览区全量渲染一次约 1.7 秒。重构后的数据冷启动打开到可编辑约 780 毫秒加上文件选择和初始化就是标题里说的“约 1 秒”滚动过程保持 60 帧左右只是在代码块多的段落会偶发降至 45 帧输入法上屏平均延迟降到 80 毫秒左右预览区单次增量解析平均 6 毫秒只有全量解析兜底时才偶尔升到 300 毫秒。这组数据不是一个“微不足道的优化”它是把架构改成按需渲染之后才可能出现的数量级变化。打开和响应速度不再是文件大小的线性函数。4.3 重构过程中最容易踩的坑第一个坑想一出是一出没有先给旧代码做行为模型。我一开始直接重头写了不少模块但发现旧功能太依赖底层假设后来只能停了先把每个模块的输入输出和状态依赖全部列出来再动手。这个过程占了第一周的一半时间。第二个坑CodeMirror 6 的虚拟行和自定义预览区同时滚动时两边的滚动状态没同步好。用户在主编辑区滚动时预览区应该跟着动但在长文档里立即同步会导致预览区每帧都创建新节点卡顿明显。最终方案是预览区拖动时加了一个 150 毫秒防抖并在滚动结束后再校准到对应块。第三个坑Web Worker 的解析结果顺序问题。用户输入很快时Worker 的处理顺序和主线程请求顺序可能不同。如果弱网或者 CPU 繁忙旧解析结果可能后到覆盖新结果造成内容倒回。我加了请求序号校验只接受最新请求结果。这个 bug 不仔细测很难发现但一发现就是大问题。第四个坑数据量越大字符串拼接越不可信。原来预览渲染用模板字符串拼整段 HTML2 MB 文本在 V8 里反复拼接字符串会触发大量内存拷贝。重构后改用 DocumentFragment 配合可复用节点先用 createElement 创建块容器再塞内容。直观结果就是预览区卡顿大幅下降。4.4 给同样想重构 Markdown 编辑器的人三句实话如果你们也想做类似重构我有三句实在话。第一如果现有项目小于 100 KB 且没有明确的性能问题不要为了“干净架构”去重写。架构是为性能服务的不是反过来。第二2 MB 文档能不能 1 秒打开很大程度上取决于你的文本到展示链路是否做了解耦。只要渲染阶段还存在任何全量循环性能上限就锁死了。虚拟化技术和 Worker 化是加分项但最核心的是“不渲染看不见的东西”。第三优先解决首屏打开时间再考虑滚动帧率最后再处理输入响应。多数用户对编辑器最直观的感受就是打开快不快、滚动卡不卡、打字顺不顺。我不会一上来就追求所有指标完美。5. 重构结束后的维护与扩展空间现在这版编辑器已经用回了我的日常工作流里除了处理 2 MB 这类大文件普通几百 KB 的笔记打开基本都是“瞬间”完成。维护上我总结了几个小经验给 Worker 模块写单元测试很有必要解析结果变化直接影响很多 UI 行为虚拟列表的块高度测量必须做缓存并且要在窗口缩放时失效一次所有异步渲染都要有取消机制否则用户在快速操作时会出现旧任务继续抢占资源的情况。后续我计划再做的扩展有两个方向。一个是把目录大纲变成虚拟树这样长文档侧栏结构也能快速定位另一个是给代码块加上“只读大文件预览”模式超过一定体积的代码块默认折叠只展开当前查看的部分。这两个都还在用同一个原则只要是用户看不到的区域就不要消耗主线程资源。整体重构过程耗时两个月的说法其实不算夸张。中间有大量时间花在理解旧功能行为、和 CodeMirror 6 的底层机制磨合、以及用基准脚本反复验证改动上。真正常规编码时间可能只有一半。但这次重构给我的教训是大多数编辑器的卡顿不是浏览器性能不够而是代码在尝试处理远超当前视口的信息量。把视野聚焦到用户能看到和能操作的那一小部分性能问题自然就解决了。