大规模文本编辑器中HTML页面的DOM节点差量更新算法

大规模HTML编辑中，`innerHTML+=`会全量重建DOM，导致光标丢失、事件失效，性能差。改用`insertAdjacentHTML`增量插入，仅解析新字符串，保留状态，性能提升2-4倍。批量插入需先拼接再单次调用，纯文本宜用`textContent`。diff结果仅作高亮，不可直接赋给`innerHTML`。

先说结论：在大规模 HTML 内容编辑场景下，直接使用 innerHTML += 追加内容，几乎是性能与稳定性上的“自杀式操作”。它会强制浏览器序列化整个 DOM 树、拼接成字符串、再全量重建子节点，导致光标重置、选区丢失、事件绑定失效，在长文档中单次操作可能触发 50ms 以上的同步回流。相比之下，insertAdjacentHTML('beforeend', html) 只解析新字符串，不影响原有状态，性能提升约 2-4 倍。

为什么 innerHTML += 会引发光标丢失与主线程阻塞

要理解这一现象，需要了解浏览器底层的执行机制。当你在一个包含 contenteditable 区域（例如拥有超过 10K 字符的编辑器）中使用 innerHTML += newHtml 时，浏览器会依次执行：将整个容器的 DOM 树序列化为字符串、拼接新内容、再全量反序列化重建所有子节点。这一过程必然引发三个连锁问题：




光标重置：编辑器当前选中位置消失，用户需重新定位
选区丢失：例如正在高亮显示的文字，在操作后选区标记将失效
事件监听器全部失效：之前绑定在子节点上的 click、input 等事件处理器均被销毁


实际测试显示，在处理长文档时，单次操作可能触发超过 50 毫秒的强制同步回流。若此时主线程仍在执行 diff_main 等 CPU 密集型比对（当字符数超过 5000 时，单次耗时可达 200 毫秒以上），输入响应和光标渲染将完全被阻塞。简言之，用户会遭遇“打字卡顿”和“光标错乱”等问题。

利用 insertAdjacentHTML 与文档片段进行安全增量插入

为避免全量重建，以下两条切实可行的路径值得采用：


采用 insertAdjacentHTML('beforeend', htmlString) —— 仅解析新字符串，不触碰已有 DOM，从而完整保留光标位置和事件绑定。但需注意：必须确保父节点已挂载到文档中（建议添加 if (editorEl && editorEl.isConnected) 双重校验）。
若需批量插入多段内容，应避免在循环中重复调用 insertAdjacentHTML —— 正确做法是将所有 HTML 字符串收集至数组，使用 join('') 拼接后一次性插入。涉及用户输入时，务必提前进行转义，因为 insertAdjacentHTML 本身不提供 XSS 防护。
对于纯文本插入，更安全的策略是：使用 document.createElement('div').textContent = line 创建文本节点，然后通过 appendChild() 添加。这样可彻底绕过 HTML 解析的开销。


diff 结果不能直接赋值给 innerHTML，需采用语义化 patch

目前许多编辑器使用 htmldiff.js 生成差异标记，输出包含  /  的 HTML 字符串。然而一个关键误区在于：该结果并非可执行的更新指令，仅作为可视化高亮标记。直接将其赋值给 innerHTML 只会展示差异，而无法实现局部 DOM 更新。

有效的 patch 需要满足以下条件：


输入必须是合法的 HTML（未转义的 & 和 < 会破坏解析流程），建议先使用 DOMParser 解析，再通过 serialize 进行标准化。
不处理