接手这个活儿之前我自己其实是有点不以为然的。Markdown 编辑器能有多卡无非就是解析一遍、渲染一遍顶多文件大一点让人多等两秒。直到同事把一段 2MB 的文档丢进来编辑器直接白屏十几秒CPU 吃满鼠标指针都快动不了我才意识到问题没那么简单。重构花了整整两个月最后把 2MB 文档的打开时间压到约 1 秒中途踩了不少坑也把很多“感觉应该很慢”的环节逐一量化验证了。这篇文章就把整个重构过程中最关键的技术选型、性能优化方案、实测数据以及后来排查出来的各种诡异问题完整记录下来希望对折腾 Markdown 编辑器或者大文档渲染的朋友有帮助。1. 重构前的一地鸡毛老编辑器到底慢在哪1.1 现象不是“卡”是打开即报警老版本编辑器是当时为了让产品尽快上线直接用contenteditable配合一段现成的开源解析脚本攒出来的。正常写几百行 Markdown 完全没问题语法高亮、同步滚动、预览面板都有。但产品上线后有用户陆续拿它当主力笔记工具几万字的技术文档、十几章的连载小说、整本开源手册的 Markdown 导出全都往里面灌。最夸张的一个工单反馈说打开一份 2MB 左右的 Markdown 文件等了半分钟都没渲染出来最后直接把我们客服的浏览器干崩溃了。我当时做的第一步不是改代码而是复现问题。找了一份真实的 2MB Markdown 文件在本地开发环境打开用 Chrome Performance 记录了一份完整的时间线。数据非常直观文件读取与初始化约 300ms这部分还说得过去。全量 Markdown 解析约 4.2s几乎阻塞了主线程。渲染全部行到 DOM约 3.1s生成了 60000 多个 DOM 节点。样式计算与布局约 2.5s。用户首屏感受到“能操作”合计超过 10s。也就是说用户要等十秒以上才能看到一个能交互的页面。这还不算后续滚动时的卡顿因为整个 6 万节点全都挂在 DOM 树里滚动时浏览器要不断计算所有节点的位置帧率经常掉到 10fps 以下。这种体验已经不是“优化一下”能解决的必须重构整个渲染链路。1.2 用 Performance 面板定位三大瓶颈用 Performance 面板仔细看调用栈问题集中在三个层面。第一个是“全量解析”。老代码把整个 Markdown 字符串一次性丢给解析器解析完成整个语法树之后才进入渲染阶段。2MB 文本大概包含 20 万行tokenize 阶段要遍历每个字符去识别标题、粗体、代码块、列表嵌套等语法。这个阶段还混入了大量高亮规则每个 token 都要跑一遍正则表达式导致解析时间爆炸。第二个是“全量渲染”。拿到语法树之后代码直接把所有行的 HTML 拼接成一段超长字符串一次性塞进容器。浏览器需要为每一个列表项、每一个段落、每一个代码行创建独立的 DOM 节点。一个 2MB 的 Markdown 文件生成的 HTML 节点数超过 6 万而且行内还嵌入了大量span标签用于代码高亮实际 DOM 数量可能接近 10 万。一次性创建这些节点主线程直接卡死。第三个是“同步阻塞”。整个过程发生在主线程上没有任何异步或分帧处理。解析、生成 HTML、插入 DOM、样式计算全部连续执行中间没有给浏览器任何喘息的机会。用户看到的界面就一直停在白屏状态直到整个流程完成。这三个瓶颈其实指向同一个核心问题我们是用“处理普通文档”的思路在处理大文档把 2MB 的文本当作一个不可分割的整体。但 Markdown 这种格式天然是“流式”的可以按行、按块来处理。这为后面的重构留出了巨大的优化空间。1.3 性能目标的量化拆解重构开始前我和团队把性能目标整理成了三个可量化的指标避免“感觉快了”这种主观判断指标目标值测量方式大文件打开时间2MB 文档 ≤ 1s从点击打开到界面可交互、内容完整可见输入响应击键到光标移动/内容更新 ≤ 100ms在 2MB 文档中持续输入文字测量输入事件到渲染更新的耗时滚动流畅度支持快速滚动且无明显白屏打开 2MB 文档快速拖动滚动条记录掉帧情况这三个指标中打开时间是第一优先级也是用户感受最强烈的部分。输入响应和滚动流畅度属于“持续体验”在打开大文档之后同样关键。后面的所有技术方案基本都是围绕这三个指标展开的。2. 框架与解析器选型先做减法再做优化2.1 为什么选了 CodeMirror 6而不是 Monaco 或自研编辑器核心选型是比较早确定下来的。市面上主流方案有 Monaco、CodeMirror 6、以及基于 contenteditable 的自研方案。Monaco 是 VS Code 同款编辑器功能强大但它本身是针对代码开发场景设计的默认加载体积巨大对移动端和 Web 嵌入场景非常不友好。更关键的是Monaco 对“超大文档 实时 Markdown 预览”这种组合并没有特别优化直接塞 20 万行文本进去打开时照样会卡。CodeMirror 6 是完全模块化的架构核心只包含编辑状态管理和基础编辑操作语法高亮、自动补全、代码折叠这些功能都以插件形式加载。它内部实现了虚拟行管理器不会为不可见行创建真实 DOM 节点渲染性能天然比全量 DOM 方案高一个量级。而且 CodeMirror 6 的 state 管理是 immutable 的可以很方便地拿到行变更信息为后面的增量渲染提供基础。实际测试中CodeMirror 6 打开 20 万行纯文本的成功率远高于其它方案我们最终选了它。其实我们也试过基于textarea overlay方案自研也就是用一个透明的 textarea 叠在格式化后的内容之上模拟光标位置。这个方案在简单场景下很香但一旦涉及多行代码块、超过一屏的列表嵌套、或者复杂的行内语法高亮光标定位就会出现各种偏差调试成本极高。考虑到项目周期只有两个月自研方案被直接放弃了。2.2 解析器选型markdown-it 还是 marked解析器是 Markdown 渲染的核心。我们需要一个 tokenizer 性能可控、插件系统完善、社区活跃度高的库主要考察了 marked 和 markdown-it。marked 非常轻量API 也简单几行代码就能把 Markdown 转成 HTML。但它的 tokenizer 设计相对老旧很多扩展能力需要 hack 源码想针对大文件做增量解析比较困难。markdown-it 则采用了类似插件系统的架构每个语法规则都是独立的 tokenizer可以通过插件机制精确控制解析粒度。它还内置了官方的 HTML 转义机制安全性比手动拼字符串强很多。性能上markdown-it 在原生的同步解析模式下对于 2MB 文本的解析时间大约在 2 到 3 秒之间也不算快。但它提供了对 token 流的完全控制我们可以先只解析可见区域附近的文本块而不是一次性解析全文。这种“局部解析”能力是选择 markdown-it 的决定性理由。最终我们选用了 markdown-it并在它基础上写了调度器和增量更新逻辑后面会详细说明。另外我们也实际对比过 remark / unified 生态。remark 的 AST 设计很优雅插件系统也非常强大但整体的编译链路偏重initial parse 的性能比 markdown-it 慢不少。对于既要快、又要支持自定义渲染的编辑器场景markdown-it 确实更合适。2.3 锁定的整体架构虚拟滚动 增量渲染 异步调度选型结束之后整体架构的思路也清晰了核心是两层数据层和渲染层。数据层负责维护 Markdown 文档的语法树但树不是一次性构建的而是按“块”懒加载。一个块可以是单个段落、一行标题、一个代码块、一个列表项等。编辑器初始化时只解析首屏可见的块其余块在用户滚动到附近时才解析或者利用浏览器空闲时间在后台逐步解析。这样即使文件是 2MB初始化阶段的解析量也只有几 KB时间自然降下来了。渲染层的核心是虚拟滚动。页面中永远只渲染视口内的行配合一小段缓冲区域。用户看到的永远是屏幕范围内的内容超出视口的行不会创建 DOM 节点。CodeMirror 6 自带的行管理机制帮我们解决了大部分虚拟滚动问题但 Markdown 预览面板仍然需要自己实现虚拟滚动。预览面板的解决方案是用一个固定高度的占位容器撑起总滚动条然后用position: absolute将可见块渲染在对应位置滚动时动态装载/卸载实际内容。调度层负责把“懒加载 增量更新”用合理的策略串联起来避免主线程被一次性大任务阻塞。这一层用到了requestIdleCallback、requestAnimationFrame和Web Worker在后面的实现部分会详细展开。3. 核心模块实现把 2MB 文档拆成“看得见的部分”3.1 分块解析与懒加载不急着处理整个文件我们针对 markdown-it 写了一个“块解析器”封装。首先把原始 Markdown 文本按空行切分成若干逻辑块每个块保存自身的起始行号、结束行号和文本内容。编辑器初始化时只取视口范围内的块调用 markdown-it 的parse方法解析这些块生成 HTML其他块暂时不处理。懒加载的触发时机有两个一个是滚动事件当滚动接近某个未解析的块的边缘时提前解析它。另一个是浏览器空闲时段利用requestIdleCallback在用户什么都不做的时候批量解析未处理的块但每批次数量有限制避免长时间占用 CPU。当用户正常阅读/编辑时未解析的块在后台悄悄变成“已解析”状态用户完全感知不到。这里的难点在于边界情况。比如一个很长的代码块横跨多个滚动屏按空行切分就会把它切碎。因此切块逻辑不能只看空行还要识别代码围栏、引用块、列表缩进等上下文。我的做法是先做一次轻量扫描先识别出代码块围栏的位置把整个代码块当成一个“不可分割块”然后再在其余区域按空行切分。这样至少能保证一个代码块不会被懒加载机制拆得七零八落。分块解析带来的一个额外好处是解析结果缓存。每个块一旦解析就把它的 HTML 保存下来下次滚动回来看时直接取缓存不再重算。编辑时只使当前编辑位置所在块以及可能受语法影响的前后一两个块的缓存失效其余块全部继续复用。3.2 虚拟滚动渲染一屏之外的 DOM 全部砍掉预览面板的虚拟滚动实现可以单独拆出来说一下。整体思路是给滚动容器一个总高度这个高度等于“预估行高 × 总行数”。然后根据滚动容器的scrollTop算出哪些行需要显示只渲染这些行。但 Markdown 渲染出来的行高度是不固定的标题和正文的行高可能相差很大代码块内的换行也会影响高度。预算不准滚动条就会跳动。我当时的做法是“预估 实测校准”第一帧先用固定行高渲染渲染完成后测量每个实际 DOM 节点的高度把实测高度写回一个高度表后续滚动时使用实测高度重新计算位置。如果内容被编辑修改高度表也会随增量更新同步修复。虚拟滚动容器的结构大致是这样的div classscroll-container styleoverflow: auto; position: relative; div classspacer styleheight: 200000px;/div !-- 撑起总高度 -- div classcontent-layer styleposition: absolute; top: 0; left: 0; width: 100%; !-- 根据 scrollTop 动态渲染当前可见块 -- /div /div渲染逻辑可以用一个简单的函数表示function renderVisibleBlocks(scrollTop, viewportHeight) { const startIndex findBlockIndexByY(scrollTop - BUFFER_TOP); const endIndex findBlockIndexByY(scrollTop viewportHeight BUFFER_BOTTOM); for (let i startIndex; i endIndex; i) { if (block[i].dom null) { block[i].dom renderBlockToDOM(block[i]); block[i].dom.style.position absolute; block[i].dom.style.top getBlockY(i) px; contentLayer.appendChild(block[i].dom); } } // 移除超出范围之外的 DOM for (let i currentStartIndex; i startIndex; i) { if (block[i].dom) { block[i].dom.remove(); block[i].dom null; } } }这里有两个关键点。一个是要加缓冲区域比如视口上下各额外预留 500px 的内容这样用户快速滚动时不会立刻看到空白。另一个是滚动事件要配合requestAnimationFrame做节流不能在每次 scroll 回调里同步渲染大量内容否则滚动本身会变卡。3.3 增量更新编辑只重算受影响的行增量更新是提升输入体验的核心。CodeMirror 6 的 update 回调会告诉我们文档的变更范围包括起始行号、结束行号以及变更后的文本内容。Markdown 解析的增量更新逻辑是接到变更范围后把变更块重新解析同时把与它相邻的块也纳入重算范围。为什么要连带相邻块因为 Markdown 中一个列表项的修改可能影响下一个列表项的嵌套层级引用块里的空行可能改变引用块的结束位置。如果只重算当前块很容易出现多级列表缩进错乱。实现时我们维护了一个“脏块集合”。当 CodeMirror 触发 change 时把变更影响到的块标记为 dirty然后异步处理这些脏块。处理过程中如果发现某个块的解析结果相较于旧缓存发生了变化就更新对应的 DOM 节点并把它的高度变化记录到高度表中。如果高度变化导致后续块的 Y 坐标变动还需要同步位移滚动容器内的其他节点。这个流程在实现上有很多小细节。比如用户快速输入时脏块会不断累积。为了避免每次都做全量重算我加了一个 100ms 的节流窗口在这段时间内多次变更会合并成一次重算。另一个细节是用户输入时经常只是加一个字符但 markdown-it 会重新整块解析解析出来的 DOM 结构和之前的可能完全不一样。为了减少 DOM 替换带来的闪烁我用了一个简单的 diff 逻辑对比新旧 HTML 字符串如果变化很小就只更新文本节点不重建整个块容器。增量更新还需要处理光标位置。因为 DOM 是动态渲染和销毁的如果光标在某个被卸载的块里输入就会丢失。CodeMirror 6 自身处理了这个问题但预览面板的滚动同步需要考虑这一点。我采用的是预览面板滚动时不会卸载当前正在编辑的行所在的块确保编辑器侧和预览侧永远不会“失联”。3.4 长文档的锚点跳转与滚动定位老编辑器里有“从目录跳转到对应标题”的功能。全量渲染时代这个功能很好实现因为所有标题的 DOM 节点都存在直接在 DOM 里查元素位置就行。但虚拟滚动之后未渲染区域的节点根本不存在无法直接获取位置。我的解法是维护一个“标题索引”在分块解析时如果某一块是标题块把它的文本、级别、所在块编号记录下来。跳转时根据标题文本查索引找到对应块编号然后从高度表累加该块之前所有块的高度得到目标 Y 坐标再设置滚动容器的scrollTop。因为高度表是实测校准过的这个 Y 坐标在大文件下误差不会超过一两像素足够精确。同样的问题也出现在“保留编辑位置”上。用户编辑到第 5000 行刷新页面后CodeMirror 6 可以通过history插件恢复滚动位置但预览面板是独立的 scrollTop必须在渲染完成后从高度表反向计算位置。我们的解决方案是在 update 回调中持续记录当前可见的第一个块编号。重新打开文档时在文档内容恢复和分块解析完成后再用块坐标倒推出滚动位置用户感知上就是“刷新后停留在原地”。锚点跳转这块有一个坑如果跳转目标块的解析缓存还没生成直接滚过去会显示空白。解决方法是跳转前先强制解析目标块以及目标块上下各 5 个块确保滚动到目标位置时内容已经渲染完成。这个预解析操作非常快用户体验上基本就是“秒达”。4. 实测数据与调优记录1 秒是怎么炼成的4.1 重构前后的性能对比重构完成之后我们用同一份 2MB Markdown 文件做了完整的性能测试。测试环境是本地 Chrome 120CPU 8核内存 16GB关闭所有浏览器扩展。结果如下项目重构前重构后打开到可交互约 10s约 0.8s解析生成 HTML约 4.2s首屏约 80ms后台总解析约 2.4s不阻断DOM 节点总数约 60000视口内约 200 ~ 400输入响应延迟数百 ms频繁卡顿50ms 以内快速滚动掉帧率高明显卡顿基本稳定 60fps内存占用约 450MB约 120MB其实后续整体后台解析完所有块仍然需要约 2.4s但因为是在requestIdleCallback里分批做的用户完全感知不到。真正让“打开 2MB 文档”变成 1 秒级体验的关键不是把全部解析压缩到 1 秒内而是把解析从“打开文档前的阻塞任务”变成“打开文档之后慢慢做的后台任务”。用户先看到内容、先能操作优化目标就已经达成了。首屏从打开到可交互的 0.8s 中具体构成大致是文件读取 初始化约 200ms首屏块解析约 80ms虚拟滚动首次渲染约 300ms其余为浏览器布局与绘制时间。整体符合预期还有进一步压缩空间但已经不会对用户造成困扰。4.2 调优中的几个意外发现调优过程中有几个现象特别值得记录。第一个意外是“字体对滚动性能的影响”。我们在测试滚动流畅度时发现某些段落渲染后会出现明显的闪字现象快速滚动时帧率骤降。排查了很久发现是因为页面加载了自定义字体而浏览器在滚动时来不及为新增的 DOM 节点加载字体字形导致文字重绘。解决办法是把自定义字体换成系统字体栈或者提前用font-display: swap降低影响。这个坑一开始完全没想到。第二个意外是“图片解码会阻塞滚动”。测试文档里有一篇包含 20 张本地图片的文章每张图片都经过 base64 编码直接嵌入 Markdown。渲染到包含图片的块时浏览器需要解码图片这一步极其消耗 CPU导致滚动瞬间掉帧。我的处理是图片区域先渲染成一个固定大小的占位符真正滚动到附近时才加载真实图片。这算是一个简单的懒加载实现但效果非常明显。第三个意外是“正则回溯导致解析卡死”。有一份文档中连续出现了大量嵌套引用和嵌套列表markdown-it 的某些规则在这类文本上出现了性能退化解析耗时从几十毫秒暴涨到几秒。通过给解析任务加超时控制并把这类文档标记为“复杂文档级别”切换到更保守的解析策略才彻底解决了。这也说明只依赖解析器的内部优化是不够的应用层仍然需要防护机制。4.3 稳定性与内存占用观察重构后内存占用从 450MB 降到 120MB很大程度上得益于虚拟滚动。在长时间使用测试中我把一个 2MB 文档来回滚动、编辑、保存持续一个小时内存曲线非常平稳没有出现明显的持续增长。这主要归功于块缓存和 DOM 回收机制滚动离开视口的块DOM 会被移除但解析结果和 HTML 缓存仍然保留在内存中。如果缓存完全释放内存占用还能进一步下降但考虑到用户来回滚动会很频繁保留缓存能显著提升流畅度这个取舍是值得的。不过我们也发现了一个边界情况如果文档包含超大代码块比如一个连续几万行的代码段虚拟滚动在这个区域基本失效因为整个代码块是一个不可分割的块它内部必须整体渲染。后续针对这种场景做了一个单独的处理在代码块内部再做虚拟化按代码行粒度渲染同时通过查看“代码块内行号”来维持编辑器的滚动同步。这个改造上线之后再也没有出现“打开带超长代码文档直接白屏”的反馈。5. 常见问题与排查技巧重构后才踩完的坑5.1 大表格与复杂语法的渲染灰色地带Markdown 表格在某些文档里会非常宽几百列的长内容可以把页面撑得无法直视。虚拟滚动对表格的处理也是重灾区因为表格不能像段落一样随意切割。我的处理是对表格块做特殊标记渲染时外层加横向滚动容器超过 800px 宽度的地方直接启用横向滚动同时在表格内部也做虚拟化只渲染视口范围内的行和列。如果表格本身特别大用户又能接受折叠表格可以加上“表格折叠插件”默认只展示前 10 行点击展开才显示完整表格。这样在保持虚拟滚动机制的同时也兼顾了实用性。数学公式也是一个容易踩坑的点。原先使用 KaTeX 来渲染行内公式和块级公式但公式渲染的速度比普通 HTML 慢很多。在包含大量公式的文档中首屏解析时间会明显增加。后来我给公式块增加了缓存机制同一个公式渲染过一次之后后续直接复用生成的 HTML 和样式不再重新执行 KaTeX 渲染。这个方法对重复公式特别有效文档里的公式数量如果很多性能提升通常在几十倍以上。5.2 滚动时白屏闪烁问题虚拟滚动的一个常见副作用是快速滚动时出现白屏或闪烁主要是因为新渲染的内容来不及绘制或者旧内容提前被卸载。我处理这个问题有三板斧。第一板斧是加大缓冲区域。默认在视口上下各额外渲染 500px 的内容快速滚动时这些缓冲内容能提供“视觉缓存”给新内容的渲染争取时间。第二板斧是延迟卸载只有当块滚出视口的距离超过 1000px 时才真正移除 DOM而不是滚出可见区域就立刻卸载。这样来回小范围滚动时很多内容根本不需要重建。第三板斧是给内容的出现加一个默认的“正在渲染”占位样式如果某一帧确实来不及渲染先显示一个和文档背景色一致的占位块避免用户看到刺眼的白底闪烁。这三招配下来快速滚动时的白屏问题基本消失偶尔在极端快滚的时候会出现短暂占位但不会让用户感觉页面崩溃。5.3 旧文档兼容与键盘习惯迁移用户手里可能有大量用老编辑器保存的 Markdown 文件其中有些语法在新的解析器下可能会呈现得不太一样。我们专门做了一个“兼容模式”在老编辑器上打开时自动把旧的换行符\r\n归一化为\n并把老编辑器生成的特殊占位符转换成标准 Markdown 语法。这个功能看似简单但它是老用户愿意继续使用新版编辑器的重要前提。键盘习惯迁移也是一个说起来不大、却很影响体验的点。很多老用户习惯用 Tab 键增加默认缩进进入 Markdown 代码块时按 Enter 自动缩进退出列表时连续按两次 Enter 退出列表。重构过程中我们把 CodeMirror 6 的 keymap 配置成和老编辑器一致的键位并把常用快捷键整理成一张对应表放在了设置页。做完这件事之后内部吐槽“新版太别扭”的声音明显减少了。5.4 性能验证的自动化手段性能优化如果不能持续回归验证过几个月很容易回退。我们搭建了一个简单的性能监控流程步骤如下先在测试文档集里准备好几份不同大小、不同复杂度的大文件然后在 CI 中跑一个自动化脚本用 Puppeteer 打开编辑器记录以下数据初始化耗时、首屏白屏时间、滚动帧率采样、内存峰值、大文件打开总耗时。每次提交代码后自动跑一遍如果打开 2MB 文档的时间超过 1.2s就视为性能回归直接阻止合并。这个流程在重构后半段帮了大忙。有一次改动区块缓存策略自测感觉没什么问题但自动化测试立刻发现打开时间从 0.8s 涨到了 1.5s仔细排查才知道是缓存 key 设计不合理导致了多余的解析开销。如果靠人工测试这种问题很可能被拖到上线后才暴露。结尾重构后的几点体会两个月重构下来我最深的体会是性能优化一定不要靠感觉先用工具量化再决定优化方向。很多看似“理所当然”的性能瓶颈实际测量之后可能根本不是问题而一些完全没预料到的角落——比如自定义字体、图片解码、正则回溯——才是真正吃掉性能的地方。我自己在实际操作中还有一个特别想分享的小技巧优化大文档时永远先看“用户第一次看到内容”的时间而不是“整个文件处理完”的时间。你不需要在打开文件时就把所有内容都准备好只需要让用户能立刻看到首屏、能立刻输入剩下的解析完全可以放到后台慢慢做。这个思路放在 Markdown 编辑器上也适用于任何涉及大文件、长列表的 Web 应用。如果你也在折腾 Markdown 编辑器或大文档渲染建议先把这篇里的虚拟滚动、增量渲染和懒加载思路跑一遍再根据自己项目的实际情况调整。性能这条路没有银弹但把这几招用熟2MB 文档 1 秒打开并不是什么够不着的目标。