企业官网建设流程全解析

1. 为什么我会花两个月去重构一个 Markdown 编辑器

我自己维护了一个 Markdown 编辑器，不算大，但每天都有几百个人在用。最开始它就是一个简单的 Web 端工具，支持左侧写、右侧预览，用户粘性还不错。直到某天有人往里面塞了一个 2MB 的 Markdown 文件，页面直接卡死，浏览器弹出“无响应”。从此我开始意识到，这不是用户的文档太夸张，而是我在最开始写代码的时候，就没想过会有人在里面写一本20万字的技术手册。

这个项目的重构断断续续做了两个月，最终达到的效果是：2MB 文档约 1 秒打开，输入响应稳定在 60 帧上下。这篇文章就是想把这两个月踩的坑、做的取舍、验证过的方案完整记录下来。适合那些正在做编辑器类应用、或者遇到长文档性能问题的人参考，哪怕你完全不用 Markdown，里面的解析、渲染、虚拟滚动思路也照样能迁移到自己的项目里。

1.1 最初的问题：“能跑就行”的编辑器

老版本功能不算少：支持 GitHub Flavored Markdown（GFM）、任务列表、代码高亮、表格、图片拖拽上传。代码结构也很清晰，一个文件负责解析，一个文件负责渲染，一个文件负责快捷键。但所有逻辑都围绕一个核心假设：文档很小。小到可以随便字符串拼接、随便遍历整棵 AST、随便在每次输入时全量重新渲染。

这个假设害了我。Markdown 属于轻量标记语言，写起来舒服，但真到了“备忘录变成长篇连载小说”的程度，性能问题就全暴露了。比如 2MB 的 Markdown 文件，大约有几十万字符，几十万个 Token，几千个块级节点。老版本的做法是：每次键盘按下，立即解析全文，生成 HTML 字符串，然后整体替换预览区的内容。这在 50KB 文档时还能忍，到了 2MB 就变成灾难。

更要命的是，不只预览区卡，连编辑区也卡。有些编辑器为了保持编辑区和预览区的滚动同步，会在每次输入时重新计算所有行的高度，更新滚动位置。这些操作叠加在一起，直接把用户输入卡到了 200ms 以上延迟，难怪浏览器会提示无响应。我第一次用性能分析工具抓火焰图时，看到innerHTML = html那一行占了主线程 78% 的时间，整个人都不好了。

1.2 性能瓶颈到底在哪：从用户反馈到火焰图

重构之前，我花了一周时间只做一件事：定位瓶颈。用户反馈最多的问题按次数排序分别是：打开大文件很慢、输入卡顿、滚动掉帧、预览和编辑不同步。表面上看是四个问题，实际上一查，根源只有一个：所有操作都在主线程上同步执行，而且每次都处理全量数据。

我用 Chrome DevTools 的 Performance 面板录制了一次打开 2MB 文档的过程，结果非常直观。脚本执行时间 4.6 秒，其中 Markdown 解析占 2.1 秒，HTML 渲染占 1.8 秒，浏览器布局和绘制占 0.7 秒。这还没算文件读取和编码转换。再深入看调用栈，解析器用的是正则表达式递归匹配，正则回溯导致大量时间浪费，且解析出的抽象语法树（AST）没有缓存，预览区每次全量构建 DOM 节点，光创建几万个 DOM 元素就够浏览器喝一壶了。

我也专门测了输入性能。每按一个键，全文重新解析一次，一次大概 200ms。连续打字时这些任务在事件队列里排队，表现就是卡顿、丢字。这里有个很反直觉的点：你以为卡是因为电脑配置低，其实完全不是，而是算法复杂度是 O(n) 甚至更糟，文档变大，耗时线性飙升，最终撞上主线程的帧预算。

1.3 重构目标：不换技术栈，只换思路

确定重构后，我给自己制定了三个原则。第一，不换技术栈，继续用原生 JavaScript + Markdown 社区库，因为换框架的重构成本太高，而且旧编辑器已经积累了不少用户习惯；第二，不追求“无敌快的即时解析”，而是追求“用户感知不到等待”，也就是尽量把耗时移到后台，让界面先响应；第三，每一步优化都要有数据支撑，不做“我觉得快了很多”的玄学优化，每次改动都用 Performance 面板和内存快照对比。

这三个原则非常重要，尤其是第一个。很多人一听重构，就想趁机把 Vue 换成 React，或者把 JavaScript 换成 TypeScript，结果重构了三个月，功能没加多少，性能还更差了。我的做法是在保持对外接口不变的前提下，把核心的解析和渲染链路整个换掉，这样用户无感，功能不退化，风险也可控。最后我用了两个月的业余时间，两周做方案，六周写代码，两周回归测试，总算在目标时间内完成了。

2. Markdown 编辑器的核心链路：从文本到视图

要理解这次重构，必须先看清楚一条 Markdown 编辑器最核心的数据流：输入文本 -> 分词 -> 构建 AST -> 生成 HTML 字符串 -> 解析成 DOM 节点 -> 插入到预览区。编辑区还有另一条线：输入 -> 更新内容 -> 语法高亮 -> 行号更新 -> 滚动同步。两条线在键盘事件时交汇，处理不好就会互相拖累。

很多前期设计决定都取决于你是否理解这条链路。比如为什么 Markdown 解析不能用正则硬杠？因为 Markdown 语法是分层的：行内代码套着链接，链接里又可以有强调，区块引用里还能嵌套列表。正则表达式本质上是有限状态机，处理这类嵌套结构天生吃力，还会出现“回溯爆炸”。我需要把这一层讲清楚，才能解释后续为什么花了大量精力选型解析器。

2.1 解析器选型：正则一时爽，AST 才是正解

老版本用的解析器是 marked。这个库很成熟，体积小，但它的输出格式是 HTML 字符串，而不是 AST。这就带来一个问题：当你只是为了改一个标题的样式，也不得不重新生成整个 HTML，再整体替换到 DOM 里。而且 marked 的渲染过程没有 diff 机制，老 DOM 会被直接销毁重建，滚动位置、选中状态、图片加载状态全被重置。

重构时我对比了几个候选：markdown-it、remark、micromark。最后选了 remark 系列（具体是remark-parse+remark-rehype+rehype-stringify）。原因很简单：它把解析和渲染彻底拆开，输出的是标准的 unist AST，可以精细地做增量更新、缓存和各种插件处理。虽然体积比 marked 大不少，但对一个桌面级编辑器来说，运行时性能远比体积重要。

这里想多说一句选型经验。不要只看 GitHub Star 数量和下载量，要看数据模型是否匹配你的场景。marked 适合“一次性把 Markdown 转成 HTML 塞到页面里”，而我要的是“能缓存、能更新、能跟踪节点变化”的 AST。remark 的 AST 是纯 JSON 对象，可以序列化、可以缓存、可以 diff，这为后续的增量渲染打下了基础。选型本身不是越新越好，而是越贴合需求越好。

2.2 渲染管线：HTML 生成、diff、DOM 更新

有了 AST 之后，渲染管线就能分成三步：AST 到 HTML 字符串，HTML 字符串到 DOM 节点，DOM 节点到可见视图。常规做法是直接把第二步和第三步合并，用innerHTML一把梭。但这样会导致整块预览区都被替换，性能损耗极大。

重构后的做法是先建立一份虚拟 DOM 快照。每次解析完生成新的 AST，并不急着渲染，而是跟上一份 AST 做对比，找出哪些块节点新增、删除、修改，然后只更新对应的 DOM 节点。具体用的是类似simple-diff的算法，针对树形结构做前后比较。因为是 Markdown 的块级结构，大部分差异都是局部的，比如你只改了一个段落，那么 diff 结果往往只有这一个段落节点变化，预览区只需要更新这个段落，其他节点原封不动。

这部分实现起来比想象中复杂，因为 Markdown 的嵌套结构很深层，比如列表套列表、引用套段落。diff 算法需要递归比较孩子节点，同时维护一个 key 来记录节点的身份。我给每个块节点生成了一个稳定的标识符，基于哈希值，内容变了哈希就变，diff 时就能快速判断。实测下来，大部分输入操作只需要更新 1 到 3 个 DOM 节点，相比之前全量替换，性能提升了 50 倍以上。

2.3 编辑模型：全量重渲 vs 增量更新

编辑区是另一个重灾区。老版编辑器用的是contenteditable，每次输入浏览器都会生成一个复杂的 DOM 树，然后前端去读取innerHTML来同步 Markdown 源文本。这等于把大脑放在一个会不停重启的机器上，你怎么优化都白搭。

重构时我做了一个关键决定：放弃contenteditable，改用 CodeMirror 6 作为编辑内核。这不是偷懒，而是 CodeMirror 内部实现了非常高效的文本模型和增量渲染，支持百万行级别的文档编辑。它采用的是基于Text类的不可变字符串，以及 viewport 渲染机制，只渲染可视区域内的行，滚动时动态加载。

这个决定让“2MB 文档打开约 1 秒”成为可能。因为 CodeMirror 在初始化时并不会一次性生成所有行的 DOM，它只生成可见的几十行。它内部的行高测量和隐藏内容处理都非常成熟。相当于我把编辑器的底层重写工作交给了专业团队，自己专注在 Markdown 特有逻辑上。如果你要自己实现一个编辑器，我不建议从零开始造编辑内核，除非你想研究底层原理，否则复用成熟的代码编辑器内核是性价比最高的选择。

3. 两个月里的关键重构动作

这是整个重构最核心的部分。我按时间顺序记录了几件大改动，每一件单独拿出来都很简单，但组合在一起才达到了最终效果。这些动作包括文件读取、解析缓存、虚拟滚动、输入节流和增量高亮。我会把每一步的原理、代码示例、实测效果都写出来，方便你直接抄作业。

3.1 文件读取与二进制分块

第一个拦路虎是文件读取。用户打开一个 2MB 的 Markdown 文件，FileReader.readAsText会把整个文件一次性读入内存，并且做全量编码转换，这过程在普通电脑上就要花 300ms 左右。而且读取完成后，JavaScript 拿到的是一个巨大的字符串，后续传给解析器时又要分配一块同样大小的内存，GC 压力非常大。

优化后的方案是按照文件类型选择读取方式。如果是 UTF-8 编码的纯文本，直接读取成 ArrayBuffer，然后用TextDecoder.decode()进行流式解码，解码时设置{ stream: true }，可以分块解码，并且能提前判断文件是否存在 BOM。这样第一个字节到第一个字符的渲染不再需要等待整个文件读完，界面可以先显示“加载中”占位，然后渐进式填充。

还有一个细节：很多 Markdown 文件里含有非 UTF-8 编码的字符，比如中文 Windows 下的 GBK。直接按 UTF-8 读取会产生乱码。所以我在打开文件时会先检测 BOM，再根据内容推断编码，实在推断不出来就给用户一个手动选择编码的权利。这个功能看起来小，但实际用起来非常贴心，能减少大量乱码反馈。

3.2 并行解析与缓存策略

老版本的解析是同步的，放在主线程里，2MB 文档解析 2 秒多。重构后我做了两件事：把解析移到 Web Worker，同时给 AST 加上了持久化缓存。

Web Worker 的好处是显而易见的：解析任务不再占用主线程，界面可以保持响应。但如果只是把同步代码原封不动挪到 Worker，整体时间并没有缩短，只是不卡界面了。所以我还得优化解析本身。remark 的解析流程本身是同步的，但在 Worker 里可以改为分段解析：将大文档按语义块切分，比如按空行和标题分成多个段落，每个段落独立解析成 sub-AST，最后合并成根 AST。这样能充分利用多核 CPU，通过Promise.all并发解析多个块。

缓存策略上，我使用了基于内容哈希的缓存。文件首次打开解析完成后，把 AST 序列化成 JSON 存入 IndexedDB，同时记录文件的最后修改时间和内容哈希。下次打开同一个文件，先比较哈希，如果一致，直接读取缓存，解析时间直接从 2 秒降到 20ms。如果用户编辑了文件，哈希就会变化，缓存失效，重新解析。这套策略让“二次打开”几乎瞬间完成，实际体验非常棒。

3.3 虚拟滚动与懒渲染

打开文件快不代表界面流畅，滚动起来掉帧照样让人崩溃。2MB 文档渲染出来的 HTML 如果全部转成 DOM，那可能是几万个节点，浏览器布局和重绘成本极高。虚拟滚动是唯一正解。

预览区的虚拟滚动我实现了比较轻量级的一个：只渲染可视区域附近 300px 范围内的块节点，每块根据 AST 预先计算一个估算高度，滚动时动态计算实际高度并调整占位元素。这里有个难点：Markdown 中某些元素的高度无法提前准确计算，比如图片、代码块、表格。我的策略是分两类处理：文本为主的段落和标题，可以根据字符数和字体度量估算高度；图片和大型表格采用懒渲染，进入视口时才真正加载和计算高度，加载完成后更新总滚动高度。

CodeMirror 6 本身有自己的虚拟渲染机制，所以编辑区我基本不用操心。但编辑区和预览区的同步滚动是个新问题。解决方案是维护一个行号映射表：每个编辑区的行号对应到 AST 节点和预览区的块 ID。当编辑区滚动时，找当前首行对应的块 ID，再定位预览区的滚动位置；反过来也是同理。这个映射表在解析时构建，增量更新时只改受影响的部分，性能开销很小。

3.4 打字跟手的核心：debounce + 增量语法高亮

编辑性能优化到最后，瓶颈在输入时的实时语法高亮。CodeMirror 6 提供了增量语法解析能力，它基于 Lezer 语法系统，只重新解析发生变化的片段。但 Markdown 的语法和代码不同，它的高亮依赖上下文，比如代码块内部和外部的高亮规则不同。为了让 Lezer 正确处理 Markdown，我引入了一个名为@codemirror/lang-markdown的官方扩展，它本质上是把 Markdown 的块结构和行内代码用 Lezer 来表达。

即便如此，输入时我们也不应该每敲一个字符就立刻解析高亮。我的做法是老老实实 debounce 到 80ms。这 80ms 既能保证输入体验，又能让打字时的连续事件不会每次都触发重解析。实测下来，400ms 的输入延迟是用户能感知的临界点，80ms 完全没问题。

增量高亮的核心逻辑就是：在输入时，Lezer 会生成一个变更范围，然后我取出受影响的行，重新做语法高亮，并把高亮结果应用到 CodeMirror 的 decorations 上。整个过程只涉及几行，所以即使是很长的文档，也能做到打字跟手。

除此之外，我还对预览区做了延迟更新。编辑区的输入事件只负责更新本地状态，预览区的渲染任务通过requestIdleCallback在浏览器空闲时执行。如果用户一直在打字，预览区更新会被一直推迟，直到用户停顿，这时候再一次性渲染。这个策略虽然看起来“不实时”，但用户体验比“实时卡顿”好太多，而且用户本来就更关心正在输入的内容，而不是远处的预览。

4. 实测数据与真实体验：2MB 文档约 1 秒打开

目标到底有没有达成，不能靠感觉，得靠数字。我专门搭建了一套测试环境，把老版本和重构后的版本放在同一起跑线上，跑了一组对比测试。这里的数据都是在相同硬件和浏览器环境下得出的，我没有刻意挑选对自己有利的数据，相反，为了让结果更有说服力，我挑的测试文档非常极端。

4.1 测试环境与基准方案

测试环境：一台 2020 年的 MacBook Pro，M1 芯片，16GB 内存，系统为 macOS。浏览器使用 Chrome 118 稳定版，无痕模式，关闭所有扩展。测试用的 Markdown 文档结构包含大量中文和英文混合文本、嵌套列表、几十个代码块、几十张外部图片链接、若干表格，总共约 2.1MB，大约 35 万字符。

老版本的构建产物是重构前的最后一个提交，新版本是重构完成后的版本。为了公平，两者都使用相同的 Markdown 渲染主题样式，并且都不开启任何实验性优化选项。每次测试前清空浏览器缓存和 IndexedDB，确保是冷启动。测试共进行 10 次，取中位数和平均值。

4.2 性能对比表

我把关键指标整理成了表格，方便你直观对比：

以上数据说明，“2MB 文档约 1 秒打开”并不准确，准确说是 1 秒左右而不是超过 5 秒。冷启动包含文件读取解析和编辑器初始化，1 秒符合目标。二次打开更是快到几乎无感。内存从 620MB 降到 180MB，对于大型文档来说是个巨大的改善，用户不用再担心标签页崩溃。

4.3 内存与滚动的优化效果

内存优化主要来自三方面：不再全量生成 HTML 字符串、虚拟滚动避免了大量 DOM 节点常驻、AST 缓存复用减少重复解析。老版本 2MB 文档生成的 HTML 字符串和 DOM 节点是纯净文本的十倍以上，浏览器内存直接失控。新版本只渲染可视区域，加上 CodeMirror 本身只维护视口范围内的编辑器行，内存开销自然就下来了。

滚动方面的优化效果也很直观。老版本快速滚动时，会一次性触发布局和绘制全部节点，造成明显的白屏和卡顿。新版本由于虚拟滚动和懒渲染，滚动过程中始终只有几十个节点在更新，帧率稳定在 50 帧以上。实际体验就是跟手，能够像正常阅读网页一样滚动长文档。

不过我还是要诚实地说明一些限制。2MB 文档 1 秒打开是在 M1 芯片上测的，如果你用的是几年前的低端电脑，时间可能会长到 2 秒左右，但这个量级已经完全可以接受。另外，如果文档包含大量超宽表格或超长代码行，虚拟滚动的性能仍会受影响，因为横向滚动和代码折行处理比较复杂。这个问题我在下文的常见问题里会详细说。

5. 重构路上踩过的坑（实战排查实录）

再顺利的重构也会遇到各种奇奇怪怪的坑。这里我挑几个最典型的问题，把现象、排查过程和最终解决思路全写出来。这些坑不一定只属于 Markdown 编辑器，很多是文本处理领域的通病，希望能帮你少走弯路。

5.1 中文换行和表格渲染错位的坑

中文文本和英文有个很大的不同：中文单词间没有空格，浏览器在中英混排时的换行策略很复杂。我在虚拟滚动计算块高度时，一开始用的是canvas.measureText()来估算文本宽度，结果发现中文文本到了换行边界经常出现偏差，导致预估高度和实际高度不一致，滚动时出现跳动和错位。

排查后发现，canvas.measureText()使用的字体和浏览器排版字体可能不同，导致测出来的字符宽度和实际渲染宽度不一样。我换成了Range.prototype.getBoundingClientRect()动态获取文本节点的准确宽度，并把字体加载和 fallback 都统一设置为system-ui。同时，在预计算高度时，我预留了 10% 的余量，避免因为换行差异导致占位元素高度不够。

表格的问题更棘手。Markdown 表格在某些解析器里会生产非常宽的表格，横向溢出预览区。如果用户开启了“自动换行”，又会导致表格结构混乱。最终方案是给预览区表格加上横向滚动容器，同时关闭表格内部的自动换行，只允许表头在极端情况下换行。这个处理虽然谈不上完美，但至少不会出现单元格内容挤到下一列的问题。

5.2 图片路径和本地资源加载的坑

用户在编辑器中拖入图片，通常会得到一个本地路径或 base64 编码。如果只是把路径塞进预览区，本地路径跨域会被浏览器拦截，图片就显示不出来。另外，Markdown 文档里的图片有的是相对路径，有的带查询参数，有的使用 HTML 标签包裹，这些都增加了渲染的复杂度。

我的解决思路是搞一个资源解析层，专门处理三种图片来源：网络 URL、本地绝对路径、base64 编码。网络 URL 直接渲染；base64 解码后交给虚拟滚动懒加载；本地路径则通过编辑器增加一个代理服务器来读取，在浏览器端用自定义协议替换路径。如果是在纯前端环境里，没有代理服务器，就只能提示用户“本地文件无法预览”，但至少不会让整个文档崩溃。

说实话，图片问题至今没有完美的通用方案，不同的使用场景需求不同。如果是本地桌面应用，用 Electron 的 file 协议就能解决；如果是在网页版编辑器，就必须配合后端做文件上传。我在这块花了不少时间，最终把图片处理封装成了一个可扩展的插件接口，方便不同部署环境自定义。

5.3 长文档光标跳动与 Undo 栈爆炸

编辑长文档时，用户最容易遇到两个问题：光标跳回开头，或者 Undo 历史无限增长导致内存暴涨。光标跳动通常是因为文本模型和视图状态没有同步，比如在输入时异步更新了源文本，导致 CodeMirror 的行 ID 发生变化，光标坐标就乱了。解决方法是所有对编辑内容的修改都通过 CodeMirror 的dispatch事务来进行，确保历史记录和光标位置都能正确维护。

Undo 栈爆炸则是我在重构后期发现的。老版本里，我每次打开文件就把全文作为一个历史记录压入栈中，导致用户一按 Ctrl+Z 就回到空白文档。重构后，我引入了“合并编辑历史”的策略：连续打字时，把多个微小的输入合并成一个事务，每个事务只记录变更范围，而不是整个文档快照。同时限制 Undo 栈的最大深度为 100 步，超过就丢弃最老的历史。这样做之后，即使编辑一个 2MB 文档一整天，Undo 内存消耗也不会超过 20MB。

5.4 数学公式和代码块的折行处理

支持数学公式是 Markdown 编辑器常见的扩展需求。我在重构过程中把 KaTeX 集成到了渲染管线里，但很快发现两个问题：一是公式渲染是同步的，大量公式会导致首次渲染卡顿；二是公式节点不能随意拆分，虚拟滚动在计算高度时需要特殊处理。

我的方案是把公式渲染也改成懒加载，只有进入可视区域时才调用 KaTeX 渲染。同时，在 AST 里给公式节点添加一个“不可分割”标记，虚拟滚动时不会把公式块拆成多行，而是整体计算高度，宽度溢出时横向滚动。代码块的折行就简单多了，开启了wrap模式后，代码行可以软换行，并在左侧显示一个换行指示器，这样既能保持代码的结构，又不会拖垮渲染性能。

6. 重构之后的心得与建议

列了这么多技术细节，最后再说说我的个人体会。

第一，性能优化不能靠猜，一定要先测脉搏再开药。我一开始也以为瓶颈在语法高亮，结果用 Performance 面板一看，高亮只占很小一部分，真正的大头在解析和全量渲染。如果没有这一步测量，我大概率会在错误的方向上浪费时间。

第二，针对 Markdown 这类有明确结构的文本，AST 化是性能优化的前提。不管用哪个解析器，只要能把文本变成可操作的数据结构，后续的 diff、缓存、懒渲染就都有的放矢。反过来，如果一直停留在“字符串到字符串”的层面，优化手段就非常有限，只能不断给千疮百孔的老架构打补丁。

第三，关于虚拟滚动和增量渲染，能借力成熟的库就不要重复造轮子。这次重构最值得的一笔投资就是引入 CodeMirror 6，它帮我处理了编辑内核最复杂的一部分。预览区的虚拟滚动我原本也想找一个现成的库，但试了几个都不合适，最后还是基于自己维护的 AST 高度缓存实现了轻量版。这个取舍的关键在于：核心业务逻辑必须亲力亲为，通用组件尽量用久经考验的成熟方案。

最后想补充一个很小的优化：在文件打开时，我加入了一个快速“骨架屏”效果，显示标题层级结构，而不是一直空白等待。这虽然不直接提升性能，但能让用户感知到“程序在干活”，心理等待时间大大缩短。有时候用户体验不只有毫秒级的数据，还有这些细节的照顾。

如果你也在做类似的重构，记住一个原则：让每个操作只处理它真正需要触碰的数据，其余该懒就懒、该缓存就缓存。Markdown 编辑器如此，其他文本密集型应用也一样。想通了这一点，理论上任何 2MB 的文档，都能在 1 秒内打开。