最近我把手上那个 Markdown 编辑器项目完整重写了一遍，前后花了差不多两个月。最初让我下决心的场景很朴素：同事给我丢来一个 2 MB 左右的 Markdown 文件，里面塞了大量代码块、表格和从网页上直接复制下来的长文本，我用自己那版编辑器打开，鼠标要先转圈两三秒才能挪动，滚动起来像在看慢放视频。那一刻我意识到，问题不在文件大，而在编辑器本身的架构一直在偷懒。
这版重写完成后，同样那份 2.4 MB 的文档，冷启动打开到能编辑，基本稳定在 1 秒左右。不是开了什么秘密加速，而是把之前“全量渲染 + 全量解析 + 全量高亮”的思路整个推倒，换成“按需加载 + 分块解析 + 虚拟滚动”。这篇就记录一下我在这两个月里踩过的坑、做过的取舍，以及最后落地的核心方案。
这内容适合谁看？一类是像我一样在做本地 Markdown 工具、笔记软件、文档站后台的开发者，另一类是准备对自己的编辑器项目做性能重构、但还没想清楚从哪里下刀的人。我会把关键步骤拆开讲，也会把性能调试时最常遇到的问题直接列出来。
1. 重构前的真实状态：2 MB 文档为什么会卡成 PPT
1.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 编辑器内核选择：为什么我放弃了 contenteditable
Markdown 编辑器的主编辑区一般有两条路：用<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 MB，2.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 不仔细测很难发现，但一发现就是大问题。
第四个坑：数据量越大，字符串拼接越不可信。原来预览渲染用模板字符串拼整段 HTML，2 MB 文本在 V8 里反复拼接字符串会触发大量内存拷贝。重构后改用 DocumentFragment 配合可复用节点，先用 createElement 创建块容器，再塞内容。直观结果就是预览区卡顿大幅下降。
4.4 给同样想重构 Markdown 编辑器的人三句实话
如果你们也想做类似重构，我有三句实在话。
第一，如果现有项目小于 100 KB 且没有明确的性能问题，不要为了“干净架构”去重写。架构是为性能服务的，不是反过来。
第二，2 MB 文档能不能 1 秒打开，很大程度上取决于你的文本到展示链路是否做了解耦。只要渲染阶段还存在任何全量循环，性能上限就锁死了。虚拟化技术和 Worker 化是加分项，但最核心的是“不渲染看不见的东西”。
第三，优先解决首屏打开时间，再考虑滚动帧率，最后再处理输入响应。多数用户对编辑器最直观的感受就是打开快不快、滚动卡不卡、打字顺不顺。我不会一上来就追求所有指标完美。
5. 重构结束后的维护与扩展空间
现在这版编辑器已经用回了我的日常工作流里，除了处理 2 MB 这类大文件，普通几百 KB 的笔记打开基本都是“瞬间”完成。维护上，我总结了几个小经验：给 Worker 模块写单元测试很有必要，解析结果变化直接影响很多 UI 行为；虚拟列表的块高度测量必须做缓存，并且要在窗口缩放时失效一次；所有异步渲染都要有取消机制，否则用户在快速操作时会出现旧任务继续抢占资源的情况。
后续我计划再做的扩展有两个方向。一个是把目录大纲变成虚拟树，这样长文档侧栏结构也能快速定位；另一个是给代码块加上“只读大文件预览”模式，超过一定体积的代码块默认折叠，只展开当前查看的部分。这两个都还在用同一个原则：只要是用户看不到的区域，就不要消耗主线程资源。
整体重构过程耗时两个月的说法，其实不算夸张。中间有大量时间花在理解旧功能行为、和 CodeMirror 6 的底层机制磨合、以及用基准脚本反复验证改动上。真正常规编码时间可能只有一半。但这次重构给我的教训是，大多数编辑器的卡顿不是浏览器性能不够，而是代码在尝试处理远超当前视口的信息量。把视野聚焦到用户能看到和能操作的那一小部分，性能问题自然就解决了。
