直接用 innerHTML 更新大段 HTML 会卡死，因为每次赋值都会销毁旧子树、重新解析字符串、构建新节点并触发全量重排重绘，时间复杂度为 O(n)，对几千行 HTML 尤其明显。
为什么直接用 innerHTML 更新大段 HTML 会卡死
因为浏览器每次执行 innerHTML = newHtml，都会先销毁旧子树、重新解析字符串、构建新节点、触发完整重排重绘——哪怕只改一个字符，代价也是 O(n) 的 DOM 重建。对几千行的 HTML 片段，这相当于每改一次就做一次全量渲染。
常见错误现象：editor.innerHTML += '<li>new</li>' 在循环中使用，导致 CPU 占用飙升、编辑器无响应；或输入框光标错位、滚动位置丢失。
- 避免在编辑器内容区直接赋值
innerHTML，尤其当内容含事件监听器、焦点状态或第三方组件时 - 若必须用
innerHTML，确保新内容是完整、合法、已 XSS 过滤的字符串（如经DOMPurify.sanitize()处理） - 优先把编辑器内容视为“纯文本流”，仅在最终提交或预览时才转为 DOM 渲染
DocumentFragment 能不能用于实时编辑场景
不能直接用于高频输入场景——DocumentFragment 是离线容器，不挂载、不响应事件、不支持 querySelector，也无法保留光标位置或选区信息。它适合批量插入静态结构，但不是编辑器内部的“差量更新引擎”。
真实使用场景：编辑器导出 HTML 时，将用户输入的 Markdown 或富文本块批量转成 DOM 节点，再一次性 append 到预览区；或构建初始模板骨架。
立即学习“前端免费学习笔记（深入）”；
- 别在
input或keydown事件里反复创建 fragment 并插入——这和直接操作 DOM 没本质区别，只是延迟了重排时机 - fragment 插入后自动清空，不可复用；需多次操作就得新建多个
- 它不维护焦点、selection、scroll offset，这些必须由编辑器逻辑单独保存和恢复
真正可行的差量更新策略是什么
现代编辑器（如 CodeMirror 6、Monaco、ProseMirror）根本不依赖 DOM 差量，而是用“虚拟表示层 + 增量 patch”：把 HTML 内容抽象为可 diff 的树状数据结构（如 AST 或自定义 schema），只计算变更节点，再映射到真实 DOM 的最小修补集。
如果你在自研轻量编辑器，可退一步采用折中方案：
- 监听
input事件获取变更范围（event.inputType、selectionStart/End），提取被修改的文本片段 - 用
Range+getBoundingClientRect()定位光标所在 DOM 节点，只替换其textContent或局部innerHTML - 对插入/删除操作，用
document.execCommand('insertText')（兼容性有限）或document.getSelection().getRangeAt(0).deleteContents()配合insertNode() - 禁用编辑区的
contenteditable自动格式化（如 Chrome 的自动换行、IE 的font标签包裹），统一用white-space: pre-wrap和tab-size控制显示
编辑器性能崩坏的隐藏诱因
比 DOM 操作更常被忽略的是 CSS 和布局副作用：一个 display: table-cell 的 wrapper、未限制宽度的 pre 标签、或带 box-shadow 的嵌套 div，都会让浏览器在每次重排时做复杂几何计算。而编辑器内容越长，这种开销呈非线性增长。
- 务必关闭编辑区所有过渡动画（
transition: all是重灾区） - 避免在编辑容器上设
will-change: transform—— 它会让浏览器提前分配图层，反而加剧内存压力 - 用
overflow: hidden替代overflow: auto防止滚动条宽度动态变化引发重排 - 慎用
getComputedStyle()：它强制同步布局，在输入过程中调用等于给每一帧加锁
DOM 差量更新不是开关一开就能生效的魔法，它依赖编辑器底层的数据模型是否支持细粒度变更追踪。没这个基础，强行套用 DocumentFragment 或虚拟 DOM 只会让问题更隐蔽——比如光标漂移、粘贴异常、撤销栈断裂。先理清内容抽象方式，再决定更新路径。
