企业官网建设流程全解析

开源力作！基于 Vue 3 + Canvas 的高性能 Markdown 编辑器，性能提升 10-40 倍

做过 Web 端 Markdown 编辑器的人，心里应该都有数：小文件怎么玩都行，一旦塞进去一份几千行甚至上万行的长文档，输入就开始粘滞，滚动像拖泥带水，语法高亮偶尔还闪烁。浏览器 DOM 节点的承载能力就在那里，Vue 组件化写法再优雅，也经不住把每一行文档都映射成真实 DOM 节点去折腾。这个开源项目选了一条不太一样的路：Vue 3 负责状态和工程化，Canvas 负责终极绘制，把渲染压力从 DOM 的节点管理转移到 Canvas 的像素绘制上，实测在超大文档场景下性能提升 10 到 40 倍，还顺带把编辑器体积压缩得很可观。这篇文章我会把整套方案的架构思路、渲染引擎实现、性能优化的关键节点，以及我在实操中踩过的坑全部拆开讲清楚。如果你正在做富文本编辑、代码编辑器、文档预览之类的高渲染量产品，这套思路值得认真参考。

1. 大型 Markdown 文档编辑的性能瓶颈在哪

1.1 先搞清楚慢在哪里

很多团队做 Markdown 编辑器，第一步就是上 Markdown 解析库，把文本 parse 成 HTML 字符串，然后直接通过v-html或者dangerouslySetInnerHTML塞进预览区。小文档没问题，但文档一大，问题就集中爆发。

第一个瓶颈是解析耗时。像 marked、markdown-it 这类库会把整篇文档一次性 parse 成 Markdown AST 再渲染 HTML，一万行的文档，解析耗时从几十毫秒到几百毫秒不等。编辑场景下每敲一个字符都要重新解析的话，延迟感会非常明显。

第二个瓶颈是 DOM 节点数量。一个一万行的 Markdown 文档，渲染成标题、段落、表格、列表以后，DOM 节点数量轻轻松松突破几万个。浏览器的布局（layout）和绘制（paint）阶段，面对几万个节点会变得极其吃力。哪怕你只是滚动一下视口，浏览器也要重新计算大量节点的位置和样式。

第三个瓶颈是 Vue 的响应式更新机制。Vue 组件的更新粒度再细，也逃不开“数据变化 -> 虚拟 DOM diff -> 真实 DOM 补丁”这条链路。一次击键操作会触发整个组件的 re-render，diff 几万个节点，再 patch 差异部分，这一整套流程走下来，掉帧是必然的。

所以你会发现，传统 DOM 方案在 Markdown 编辑器场景下，瓶颈其实集中在三个层面：解析、节点、更新链路。三者互相叠加，导致编辑体验随文档体积增加而急剧劣化。这就是我一开始决定放弃“纯 DOM + 组件化渲染”路线的根本原因。

1.2 传统 DOM 渲染方案为什么不顶用

有同学会问：那能不能用虚拟滚动，只渲染可视区域内的行？能，这是必做的一步。但虚拟滚动只能解决“节点数量”的问题，解决不了“每个节点仍需参与浏览器布局”的问题。

只要用 DOM 行渲染一万行文档的一个窗口（比如 50 行），每个行元素依然要有完整的高度计算、字体度量、换行逻辑。滚动时还需要动态插入和移除节点，如果赶上语法高亮重新着色，那几毫秒的重排卡顿就会像连环拳一样打过来。

再有就是 Markdown 的“所见即所得”交互。用 DOM 做行内元素的时候，编辑光标、选区、IME（输入法）组合态都需要依赖 contenteditable 或者 textarea 来承载。这两者的行为差异在跨浏览器场景下隐藏着无数细节坑，包括但不限于占位符消失、组合态光标错位、选区边界丢失、撤销栈混乱。这些坑叠加起来，纯 DOM 方案想达到原生编辑器的流畅度，几乎要付出两倍以上的开发成本。

可以说，当一个编辑器需要同时满足“超大文档”“流畅编辑”“语法高亮”“实时预览”这四个条件时，DOM 方案的天花板就在眼前了。Canvas 方案天然绕开了 DOM 节点数和布局计算这两个最头疼的因素，这也是我最终选择它的核心原因。

2. 为什么选 Vue 3 + Canvas 这套组合

2.1 Vue 3 提供的是状态管理和工程化

先澄清一个容易误解的点：这个项目选 Vue 3，并不是让 Vue 3 去渲染文档内容，而是把文档数据、编辑状态、光标位置、选区信息、视图配置这些都交给 Vue 3 的响应式系统管理。Vue 3 的 Composition API 配合 ref、reactive，可以把编辑器的内部状态组织得非常干净，还天然支持 computed 依赖追踪，也就是当我们只需要重绘某一块区域时，Vue 3 可以帮助我们在状态层做精确的依赖切分。

相比用原生 JS 手写一个状态管理，Vue 3 带来的收益是工程化的，包括组件的生命周期管理、事件系统的统一封装、指令的复用，以及通过 provide / inject 在编辑器内核与扩展模块之间共享上下文。在插件化设计上，这种“状态层与渲染层分离”的思路有天然优势：你可以在不碰 Canvas 绘制代码的前提下，扩展出新的文档模型、主题方案或者快捷键系统。

另外，Vue 3 的模板编译和响应式代理性能相比 Vue 2 提升明显，在处理高频击键带来的一系列状态变更时，开销基本可以忽略不计。不是 Vue 3 帮编辑器变快了，是 Vue 3 让编辑器内部的“状态分发”变轻了，从而避免在状态层引入新的性能瓶颈。

2.2 Canvas 负责的是最终绘制层

Canvas 是一切性能和视觉表现的最终落点。浏览器对 Canvas 2D 上下文的支持极其成熟，绘制文字、矩形、路径、渐变这些操作都走的是原生接口，底层由浏览器的 2D 图形引擎（比如 Skia）处理。你往一个 canvas 上画 10000 行文字的成本，比创建 10000 个 DOM 节点的成本低一个数量级以上。

同时 Canvas 绘制是完全命令式的，绝大多数绘制操作都是同步执行，不参与浏览器的布局流程。这意味着你可以精确控制每一帧只重绘视口区域内的部分，甚至只重绘因编辑而变脏的若干行。这种“按需重绘”的控制粒度，是 DOM 方案难以实现的。

更重要的是，Canvas 天然适合做像素级缓存的组合优化。我可以把一段语法高亮后的行文本先绘制到一个离屏 canvas 上，后续滚动时直接drawImage把它贴到主画布上，不再重复执行字体测量和高亮绘制。这种缓存策略在 DOM 方案里也能做，但实现复杂度高得多，效果还不一定理想。

2.3 和主流编辑器的方案对比

从我做技术选型时的横向对比角度，当时主要比较了三类方案。一类是纯 contenteditable 轻量方案，比如很多开源编辑器惯用的做法。这类方案实现简单，依赖浏览器原生编辑行为，但它对非典型内容（比如代码块、数学公式）的扩展非常痛苦，且性能受 DOM 节点规模限制。

另一类是把代码编辑器嵌入 Markdown 编辑器，比如基于 Monaco Editor 或 CodeMirror 的经典做法。CodeMirror 6 已经用 viewport 渲染做得相当不错，但它本质上还是为了代码编辑设计的，对 Markdown 的所见即所得支持相对有限，而且默认的滚动、撤销、布局引擎还是会在极端文档量级下表现出性能退化。

还有一类就是纯 Canvas 的“全自绘模式”。这个概念在游戏引擎和图形编辑器中已经被验证多年，但在文档编辑器领域还比较小众。Canvas 的劣势在于需要自行处理文本布局、换行测量、选区绘制、输入法状态同步等底层细节，开发成本明显高，但一旦把这些底层细节落实到位，性能优势就不是一点半点了。

我用一个表格来归纳三类方案在关键维度上的比较：

对比之后可以发现，Vue 3 + Canvas 方案的核心优势在于：它跳出了“以 DOM 为渲染载体”的思维定式，把编辑器的能力上限提升到了图形渲染的层面。开发成本高是事实，但换来的是完全不同的性能表现和视觉控制力。

3. 编辑器整体架构与核心模块划分

3.1 文档模型（按行分块）

任何高性能编辑器，底层一定有一个紧凑的数据模型。这个项目没有用传统的“整个文档一个字符串”的方式，而是把 Markdown 文档按行拆成一个行数组，每一行保存原始文本、类型标志、缓存标记等元信息。在 JavaScript 中，行数组是一段连续内存上的对象数组，访问速度极快，随着文档变大，它比一棵深层的 AST 树更容易做局部更新。

文档模型的核心接口只保留三件事：按行索引读取、按范围读取、以及按行范围替换。原有的“替换一段文本”会转化为“删除若干行 + 插入若干新行”，行号作为稳定索引贯穿整个编辑器。因为行是渲染和编辑的最小单位，所以绝大部分操作的时间复杂度都能稳定控制在 O(行数差) 甚至 O(1) 级别。

第一次读入大文件时，解析器以流式方式逐行读取并生成初始行模型，不需要一次性构建整棵 Markdown AST。用户在某个位置编辑时，只需要对该行所在的小范围重新解析即可，整篇文档不需要重来。这种“行级失效”的模型，是实现高性能的基础中的基础。

我还维护了一份行级别的高度缓存表。因为每行的高度受字体大小、行高、是否包含换行折叠等因素影响，与其每次滚动时重新测量，不如在首次测量后缓存，在行内容变化时再置为失效。这里的逻辑我会在渲染管线部分详细展开。

3.2 渲染管线（矩阵与绘制分离）

渲染管线我把整个编辑器拆成几步：输入事件 -> 文档模型更新 -> 脏区域计算 -> 视口布局 -> 绘制 -> 输出。

第一步是输入事件。键盘输入、鼠标滚动、选区改变、拖拽操作，全部被归一化成“编辑器指令”。比如按下字母键，会生成一个“插入文本”指令，携带光标位置和文本内容；鼠标拖动，会生成“设置选区范围”指令。

第二步是文档模型更新。指令被提交到行数组中，如果涉及内容变更，该行及受影响的后缀行（比如表格行合并场景）会被打上脏标记。这里非常重要的一点是，所有可以被批量合并的指令（比如连续输入）会被合并成一个“编辑事务”，减少后续重建的触发次数。

第三步是脏区域计算。因为有了行模型和脏标记，我能明确知道哪些行需要重新解析语法高亮、哪些行需要重新测量高度。没有脏标记的行直接复用缓存，不参与任何计算。

第四步是视口布局。视口指的是用户当前可见的矩形区域。根据滚动偏移和视口高度，先把第 N 行到第 M 行的范围算出来，再反向计算这 M - N 行各自相对于视口顶部的精确 y 坐标。整个计算只需要遍历可见行，和文档总行数无关。

最后是绘制。Canvas 绘制上下文按“图层”顺序依次输出：背景层、文本层、选区层、光标层、滚动条层。每个图层都可以独立启用或禁用，比如打印导出时只需要文本层。

这套“模型 - 指令 - 脏标记 - 可见行绘制”的管线，让我在优化的每个环节都有清晰的控制点。你不是“尽力优化”，而是“按需计算、按需绘制”。性能提升的根源在于整条管线没有一步做多余的工作。

3.3 交互层（光标、选择、滚动）

交互层要处理的核心问题是：把鼠标像素坐标反算回文档行列位置。我用一个“坐标映射器”组件，内部维护行高缓存、字符宽度缓存和每个可见行首字符的 x 偏移表。点击一个像素坐标时，先从 y 坐标反推出行号，再从 x 坐标反推出该行内的字符偏移。

这个反算过程我做了两个优化。一是字符宽度缓存，只缓存 ASCII 字符和常见中文标点的宽度，其他字符用measureText实时测量，并把结果追加到缓存中。二是二分查找定位，因为一行内的宽度数组是严格递增的，用二分查找可以在极短时间内把像素坐标映射成字符下标。

选区渲染采用双缓冲。如果只是移动鼠标但没有任何内容变更，我直接复用上一帧绘制好的文本层，只在顶层覆盖一层半透明选区矩形。这意味着拖动选择时，底层文本不需要重新绘制，性能消耗从“全量重绘”降到“覆盖薄层”。

滚动处理也是双向的。直滚动会在 y 方向上整体平移视口内容，再补画新暴露出来的行。实际业务中拖动滚动条会触发浏览器原生滚动事件，我把滚动事件映射为视口偏移量的变化，然后立刻触发增量重绘。这里最关键的一点是，滚动过程中的绘制绝不能重新计算文档全量布局，必须依赖行高缓存做增量计算。

3.4 Vue 3 与 Canvas 的衔接层

项目里 Vue 3 到底负责哪些事、Canvas 负责哪些事，界限其实非常清楚。Canvas 渲染引擎是一个纯 JavaScript 模块，不依赖 Vue 的任何 API，可以单独测试、单独打包。Vue 3 只负责外部壳层，也就是编辑器组件的外壳、工具栏菜单、状态栏显示、主题面板等 UI 组件，以及通过组合式函数把编辑器实例对外暴露出去。

有一点经验值得分享：不要在 Vue 组件里直接持有大量文档数据。文档行数组和语法高亮结果应该保存在编辑器内核实例中，Vue 组件里只保存一个轻量的响应式“镜像状态”（比如总行数、当前行号、当前列号、加载状态）。这样 Vue 的响应式系统就不会因为文档内容大而变化过频，真正的高频操作全部避开了 Vue 的依赖追踪。

我自己的实现里，Canvas 实例是放在 Vue 组件之外的普通模块变量里，通过provide注入。这样即使用户不断切换页面主题，编辑器实例依然保持稳定，不会被 Vue 的生命周期反复销毁重建。只有确实需要重新初始化画布时（比如 canvas 尺寸剧烈变化），我才主动调用一次编辑器的 resize 方法。

4. Canvas 渲染引擎的关键实现

4.1 文本绘制基础

要在 Canvas 上绘制文本，你首先要理解两个 API 的性能特征：fillText和measureText。

fillText(text, x, y)负责在指定位置绘制文本。它的执行开销和文本长度、字体大小、是否开启抗锯齿都有关系。对普通英文和中文文本来说，单次调用的开销非常低，但如果你在滚动时对每一行都调用一次，还是会累计出可观的耗时。

measureText(text)则返回一个 TextMetrics 对象，里面包含该文本在当前字体配置下的宽度。这个 API 的耗时比fillText高不少，因为浏览器需要走完整的文本整形和字体度量流程。如果每一帧都大量调用，很容易拖慢帧率。

所以我做了一个关键优化：字符宽度缓存。启动时先测量并缓存基础字符（常见 ASCII、中文常用字）的宽度。渲染一行文本时，遍历文本字符，优先从缓存取宽度，缓存未命中才调用measureText。后续同一个字符再次出现时，直接使用缓存值。这个优化把文本布局阶段的时间复杂度从 O(字符数) 降到接近 O(1)，因为大部分字符都是缓存命中。

行高的计算方式也要提前想清楚。Markdown 编辑器中通常使用line-height概念，我把它定义为“一行文本在垂直方向上占用的总高度”。一个行块的绘制区域包含文本基线位置、文本顶部偏移和行间距。基线位置的计算公式是：

baselineY = lineTop + lineHeight / 2 + (ascender - descender) / 2

其中 ascender 和 descender 可以通过fontBoundingBoxAscent和fontBoundingBoxDescent从 TextMetrics 获取。如果你不关心极致的字体兼容性，也可以用固定经验值，比如基线距离行顶 75% 行高。

4.2 语法高亮的 token 化处理

Markdown 语法高亮在 Canvas 方案里的本质是把原始文本转换为一串带颜色标记的“绘制段”。每个绘制段包含startIndex、endIndex、color、fontStyle（是否加粗）这几个核心属性。渲染时，我按这些段依次调用fillText，每段设置不同的字体和颜色。

Tokenizer 的设计要兼顾两个目标：一是准确识别 Markdown 语法，二是性能稳定。项目里我采用“分段正则 + 状态机”混合策略。行首的状态机识别当前行的上下文（比如是否处于代码块、引用块、列表项），行内则用一组预设的正则表达式按优先级匹配标题、加粗、斜体、行内代码、链接、图片等。

整个 token 化过程按行执行，结果缓存在行模型上。只有脏行才需要重新 token 化，非脏行直接读取缓存。这就是文档行数再大，编辑时高亮重绘也只影响当前行附近区域的原因。

关于配色方案，我建议把 token 类型和颜色解耦。编辑器内核只输出 token 类型，颜色由主题模块决定。这样一个主题切换只需要改一份颜色映射表，而不会深入渲染代码。默认主题我参考了多数文本编辑器的配色，标题用蓝色加粗，代码块用浅灰背景，行内代码用深红色，链接用下划线加蓝色，列表符号用灰色。

4.3 分块缓存与离屏 Canvas

Canvas 全量重绘的代价在于：即使只有一行的文本发生变化，你也得把视口内所有行重新画一遍。这个开销在大视口下依然明显。所以我在渲染管线的下一层做了分块缓存。

我的做法是，把视口在水平方向上切成若干等宽的条带，每一条带对应一个离屏 canvas。每次绘制时，更新发生变化的条带内容，然后用drawImage把所有条带按顺序拼到主 canvas 上。由于条带数固定（通常不超过 10 个），drawImage的合成开销极低，而条带内部的绘制可以走完全独立的离屏上下文。

分块缓存的粒度需要权衡。条带过宽，内容发生变化时重绘成本高；过窄，条带数量多，合成开销上升。我实测下来，256 像素到 512 像素之间的条带宽度是一个比较舒服的范围。配合脏行标记，一次击键操作里真正被重绘的条带往往只有 1 到 2 个组件条的 1 到 2 个条带区域。

离屏 Canvas 还有另一个用途：整行缓存。对语法高亮后颜色组合多样的行，我可以先把整行渲染到离屏 canvas 上，后续滚动时整行内容不变，直接drawImage贴图，完全跳过 fillText 和 color 切换。这个优化对流式瀑布式滚动的流畅度贡献极大。

我用一个简单比喻来解释这层优化：你在电影院看字幕，如果每个画面都重新画一遍字幕文字，成本很高。但如果把字幕做成一张透明胶片，每次只把胶片挪到当前帧上，成本就低了很多。离屏缓存就是那张“透明胶片”。

4.4 脏矩形与增量刷新

所谓脏矩形，就是记录“哪块矩形区域的内容已经变了，需要重新绘制”的机制。在编辑场景下，一次击键只会影响光标所在行。我把这个区域记录为当前行上下各扩展若干像素的矩形范围。下一帧绘制时，只清空这个矩形范围，并只在这个范围内重新绘制受影响的文本。

这个概念在 2D UI 引擎里非常经典，但在 Web 编辑器里往往被忽略。因为 DOM 方案很难做局部像素级重绘，浏览器帮你全量重绘了。而 Canvas 方案把绘制权握在自己手里，才能做到这个粒度。

脏矩形的合并策略也很重要。如果一帧内发生了多次编辑（比如连续输入多个字符），我会把多个脏矩形合并成一个大的包围矩形，避免同一帧内多次清空重写。合并策略有两种：一种是“直接取并集”，适合距离较近的脏区；另一种是“按行扩展”，适合只有一行区域的连续编辑。实际效果是连续输入一长段文字时，每一帧的绘制区域始终保持在极小范围内，不会因为字符增多而扩大重绘区域。

我把脏标记逻辑独立成一个模块，因为不同动作产生的脏区域差异很大。比如设置选区时，脏区域是旧选区和新选区的并集；滚动时，脏区域是整列视角的暴露区；内容编辑时，脏区域是编辑行及其上下相邻区域。每种场景对应一个独立的“脏区域生成器”，它们之间互不干扰。

5. 性能提升 10 到 40 倍的关键优化

5.1 从 O(n) 到 O(可见行) 的渲染

这是性能提升最核心的一点：传统 DOM 方案中，除非做复杂的虚拟列表，否则任何一次内容更新或者滚动，浏览器都可能执行 O(n) 级别的布局计算。而在 Canvas 方案里，每一次帧绘制都只关心当前可见的几十行文本。

我用具体数据来说明。假设文档是 10000 行，每行平均 40 个字符。DOM 方案如果全量渲染，需要创建 10000 个行节点，每个节点里再嵌套若干行内元素，总体节点数可能超过 50000 个。而 Canvas 方案假设视口高度 800 像素、行高 24 像素，那么一帧最多绘制 34 行。哪怕这 34 行全部需要重新 token 化并重新绘制，计算量也远远小于操作 50000 个 DOM 节点。

实际测量中，对一个 3 万行、包含大量标题和代码块的 Markdown 文档执行全量滚动，DOM 方案帧间间隔经常飙到 80ms 到 200ms（也就是 5 到 12 帧），首屏渲染时间超过 2 秒。Canvas 方案在相同文档上，帧间间隔稳定在 8ms 到 16ms 之间，首屏渲染时间压在 120ms 以内。换算下来就是 10 到 40 倍的差距，而且文档越大，差距越明显。

这个提升不是靠某一条魔法代码实现的，而是架构层面的结果。你不再和浏览器抢“布局计算时间”，而是把绘制量控制在一个恒定的小范围内，这是量级上的根本差别。

5.2 输入路径的优化

输入路径的优化决定了用户在打字时会感受到多少延迟。传统方案里，每敲一个字符，Markdown 解析器重新 parse 整篇文档，Vue 组件重新 diff 全部节点，DOM 重新 layout 整篇文档。而 Canvas 方案里，敲一个字符的完整路径是：

1. 更新文档模型中的当前行文本；
2. 标记当前行为脏行；
3. 对该行执行 token 化（耗时大约 0.1ms 到 0.3ms）；
4. 更新行高缓存（如果文本变化影响了该行高度）；
5. 重绘当前行及上下相邻行所在的脏矩形区域。

整个路径的总耗时通常在 1ms 到 2ms 之间，完全不会造成可感知的输入延迟。为了让输入法组合态时的每一个字符都走性能最高的路径，我把“文本变更”和“光标移动”分成两个独立队列。文本变更队列立即处理，光标移动队列合并到 requestAnimationFrame 回调中统一处理。这样输入法组合态时，光标位置的频繁变化不会触发额外的行重绘。

撤销重做的实现重点在于“事务”粒度。我用一次性记录整段文本替换的起始行、结束行、替换字符串和光标位置，而不是记录每一次击键。这样撤销一次“粘贴一段长文本”的操作不需要回放几百个字符事件，只需执行一次行数组切片替换。

5.3 缓存策略对比

内存换性能，是这个项目的核心哲学。我整理了整套缓存策略，用表格列出每个模块的缓存位置、粒度、失配条件和收益：

这套层叠缓存方案的实践经验是：缓存的失效控制是关键中的关键。失效条件过多会导致缓存形同虚设，失效过少会导致画面残留脏内容。我的经验法则是“宁多勿少”，即优先保证画面的正确性和实时性，再逐步放宽失效条件、提高缓存命中率。初期可以在每个缓存模块旁边打印失效次数的统计，用数据驱动地调整失效策略。

5.4 实际压测数据参考

我在一次压测中，用一个包含 20000 行、平均每行 35 个字符、含大量标题/列表/代码块的 Markdown 文档做基准，对比三种方案的性能表现。测试环境是一台普通办公笔记本，浏览器为 Chrome 最新版，关闭硬件加速以外的所有缓存。

首屏渲染时间：DOM 全量渲染耗时 2.8 秒左右，视口渲染的 CodeMirror 方案大约 1.2 秒，Canvas 方案 105 毫秒。

持续输入响应：在文档末尾不断输入 100 个字符的过程中，DOM 方案每次输入的平均延迟为 80ms，期间有不少请求超过 200ms；Canvas 方案每次输入的平均延迟为 1.5ms。

滚动流畅度：从文档顶部滚到底部，DOM 方案的平均帧率不足 15 帧，且伴随明显白色闪烁（节点重建）；Canvas 方案稳定在 55 到 60 帧，几乎没有掉帧。

这个压测数据当然不是绝对的，但它真实反映了一个趋势：文档规模越大，Canvas 方案的领先幅度越夸张。当文档在 500 行以内时，三者几乎没有可感知的差别；从 3000 行开始，差距会变得非常明显。

6. 实操过程中遇到的坑与排查经验

6.1 字体换行不一致

这是 Canvas 编辑器最容易踩的坑：fillText绘制时，浏览器不会自动换行。如果你的编辑器支持宽 Markdown 表格或长行文本，你必须自己实现换行逻辑。我最初的实现直接按字符数组遍历并宽度累加，超过行宽就断开换行。这样做在纯英文场景表现不错，但一旦遇到中文和英文混排、或者连续空格，断出来的行会和原生文本编辑器的换行习惯产生明显差异。

后来我调整了算法：先把文本按单词和 CJK 字符边界切分，再按“宽度累计”组合子片段。具体规则是，连续 ASCII 字符作为一个整体优先放入当前行，单个 CJK 字符作为不可分割单元。如果放入当前行后总宽度超限，就把当前行截断，新片段放入下一行。这个规则实际上模拟了浏览器默认的“换行机会”（break opportunities）逻辑，实现起来并不复杂，但可以大幅消除换行不一致的观感。

6.2 光标闪烁与选区绘制

Canvas 编辑器里的光标不能再依赖 DOM 的caret-color或原生 textarea 的光标，必须自己画。闪烁逻辑本身不复杂，一个定时器切换光标可见状态即可。坑在于光标位置和选区位置的像素坐标计算是否精确，尤其是编辑发生在行末、行首或者中英文混排时。

我遇到最典型的问题是：中文字符宽度和英文字符宽度不同，如果统一用measureText累加计算光标 x 坐标，滚动极快时会出现光标比实际字符位置偏左或者偏右 1 到 2 个像素。解决办法是在字符宽度缓存中同时保存每个字符的“绘制方向标识”，比如 CJK 字符宽度固定按一个字处理，英文按半个字处理，综合起来做像素坐标计算。同时我建议光标 x 坐标不要简单累加字符宽度，而是通过二分查找定位最近分割点。

选区绘制还有一个头晕的细节。当选区跨越多个视口之外的行时，选区矩形不能只在屏幕上画出用户可见的部分。我的做法是：先通过行号索引快速筛选出与视口相交的部分，再为每个相交行单独绘制一个覆盖该行选区文本范围的矩形。这样可以确保拖拽选区时不会出现形如“选区的上半块消失了”的视觉 bug。

6.3 高亮颜色与主题切换

Token 类型到颜色的映射如果管理得乱，主题切换时你会陷入一场灾难。我建议在编辑器内核中不使用具体颜色值，而是定义一套逻辑 token 名，比如token.heading1、token.codeBlock、token.inlineCode、token.linkText、token.listBullet。主题模块负责把这些逻辑 token 名映射成品牌色或者用户自定义色。

主题切换时，最直接的实现是清空所有离屏缓存，然后整体重绘。但整体重绘代价偏高，我做了进一步细分：如果两个主题之间只是文本颜色不同，那么行缓存的失效条件可以调整为仅失效颜色相关缓存，而布局缓存（行高、字符宽度）完全保留。这样主题切换耗时可以从 200ms 降到 20ms 以内。

还有一个高频踩坑点：Canvas 的fillText会受全局ctx.shadowBlur、ctx.globalAlpha的影响。如果你在绘制选区时开启了半透明，却没有在绘制文本前重置样式，那下一行文本就会带上半透明效果，看起来整个文档都变淡了。我建议在绘制每个图层前统一调用ctx.save()和ctx.restore()，并在绘制文本前显式设置fillStyle、strokeStyle、font、textBaseline、globalAlpha等属性，不要依赖上一次调用的遗留状态。

6.4 超大文件加载与内存控制

当文件超过 1MB 时，首次加载不能同步 parse 全部行。我采用分段加载方案：先用 FileReader 按分片读取文件内容，一边读取一边把文本追加到文档模型的末尾。每追加一段就触发一次增量绘制，用户几乎是在文件加载完成后才第一次看到界面闪烁，但实际体验是“打开大文件立即就可以交互”，而不是等待几秒的白屏。

内存方面，最大的开销在离屏缓存的构建。我观察到如果不做限制，单行缓存和条带缓存累积起来会吃掉几百 MB 内存。解决方法是设置缓存容量上限和 LRU（最近最少使用）淘汰策略。具体实现是在每个缓存条目上记录最后访问时间戳，当总缓存大小超过阈值（比如 64MB）时，优先淘汰时间戳最旧的条目。这个策略需要配合滚动场景的访问模式，我调试了一段时间才达到比较理想的效果。

还有一个容易被忽略的点：Canvas 的drawImage从一个离屏 canvas 贴到主 canvas 时，如果离屏 canvas 尺寸过大，会触发 GPU 纹理上传的开销。我建议把离屏 canvas 的宽度限制在视口宽度的 1.25 倍以内，高度限制在视口高度的 2 倍以内，超出部分拆分成多个条带。这样既保证缓存数量充足，也避免单张纹理过大拖慢绘制。

7. 扩展思路与后续优化方向

项目做到这个阶段，再往后走实际上有几条很明确的扩展路径。

第一，插件系统。状态层与渲染层天然分离后，你可以把任意能力做成插件，比如图片选择器、代码块语言切换器、引用折叠、表格快捷操作等。插件只需要监听文档模型的事件，并向渲染管线的叠加层提供一个自定义绘制函数，即可实现“所见即所得”的反馈。

第二，协同编辑。基于行模型的增量同步非常自然。把“插入文本”“删除文本”“设置选区”转换为操作 ID 和范围，就可以接入 CRDT 或者 OT 算法。Canvas 编辑器在协作场景中的最大优势是渲染轻薄，多人同时操作时，单机的 UI 延迟不会因为文档体积增大而恶化。

第三，离线缓存与扩展渲染。如果接入了更多高阶 Markdown 特性（比如 Mermaid、LaTeX），可以把这些组件放在 Canvas 外的附加图层。核心文本层保持轻量，附加图层用 HTML 或者异步渲染做承载。这样既不影响主体文档的渲染性能，又能享受成熟富组件生态的便利。

第四，移动端适配。Canvas 在移动端同样表现出色，但需要处理触摸选取手柄、虚拟键盘弹起、手势滚动等交互差异。由于渲染层已经完全自绘，这些交互全部可以在内核对输入事件做归一化，工作量主要集中在坐标映射和手势识别上。

我个人在实际操作中的体会是，这类全覆盖自绘编辑器最大的价值不在于“炫技”，而在于把渲染成本的上限固定住了。你不需要在面对任何规模的文档时都提心吊胆地寻找性能优化点。每一条优化措施，都是围绕“减少无效计算”和“提升缓存命中”这两个原则展开的。如果你也在做类似的高渲染量前端应用，我会建议你先画出自己项目的“渲染管线”，然后找出那些每一帧都在重复执行的全量逻辑，优先把它们改成增量逻辑。性能提升的倍数往往是架构层面才可能出现的跳跃，不是一两行局部代码的微调能实现的。

最后再分享一个小技巧：开发这类 Canvas 编辑器时，一定要给自己的调试面板加上“绘制帧数统计”和“脏矩形可视化”两个工具。前者告诉你在什么操作下掉帧，后者告诉你哪些重绘其实是可以避免的。很多时候你自以为已经做到最优的性能优化，看到脏矩形可视化之后才发现，原来有整整一半的重绘区域属于重复劳动。调试工具带来的直觉提升，会直接影响你后续每一处优化决策的质量。