createDocumentFragment 能显著减少重排次数，将 N 次布局压缩为 1 次；但需配合显式节点创建、事件绑定、分帧插入（requestAnimationFrame）及性能诊断，才能在大型编辑器中真正生效。
为什么编辑器插入大量节点时卡顿，createDocumentFragment 真的管用？
HTML 编辑器（比如富文本或代码块渲染）常需一次插入几十到上千个节点——比如粘贴一段 Markdown 解析出的 200 行 <pre><code> 嵌套结构。直接循环 appendChild 每个 <span> 或 <div>，浏览器会在每次插入后尝试计算样式、布局，尤其当父容器已挂载且含 flex、grid 或复杂 CSS 时，极易触发连续重排。实测 Chrome DevTools 的 Layout 面板中能看到密集的“Layout”事件。而 document.createDocumentFragment() 提供一个离屏容器，所有节点操作不触发布局，直到最后一次性挂载，把 N 次重排压成 1 次。
createDocumentFragment 在编辑器里怎么填才不丢状态？
编辑器节点常带事件监听器、dataset 标记、contenteditable 属性或用户输入态（如光标位置、选区）。不能靠 innerHTML 字符串拼接，否则会丢失绑定的事件和 input 值。必须用 JS 显式创建并配置每个节点：
- 用
document.createElement()创建每个节点，逐个设置textContent、className、dataset.tokenType等 - 需要事件响应的节点，立刻调用
node.addEventListener()，别等插入后再批量绑——fragment 插入后节点所有权转移，但事件监听器仍有效 - 若从已有 DOM 片段提取（如剪贴板解析后的临时
<div>），用while (temp.firstChild) fragment.appendChild(temp.firstChild)安全移入，避免innerHTML赋值给 fragment（它不支持该属性）
插入目标是 <div contenteditable="true">，要注意什么？
编辑器容器通常是 contenteditable 元素，它对子节点插入更敏感：某些浏览器在插入瞬间会重置光标、触发 input 事件或强制同步布局。关键规避点：
- 不要在 fragment 中混用
insertAdjacentHTML或innerHTML—— fragment 不支持这些方法，调用无效 - 避免插入后立即读取
getSelection()或offsetHeight：这会强制同步布局，抵消 fragment 优化效果；如需定位，改用requestAnimationFrame延后读取 - 如果编辑器依赖 MutationObserver 监听变化，注意 fragment 插入只触发一次
childList变更，不是每个子节点单独触发 - 插入前确保目标容器未被
display: none或visibility: hidden隐藏——部分旧版浏览器仍可能提前计算样式
超过 500 节点时，只用 createDocumentFragment 还不够？
单次构建 fragment 本身也可能耗时（比如每节点都要做语法高亮、token 匹配、属性计算），导致主线程阻塞 >16ms，页面仍卡顿。这时得叠加 requestAnimationFrame 分帧：
立即学习“前端免费学习笔记（深入）”；
- 把节点数组按每帧 20～40 个切片，每帧新建一个 fragment，填满后立即
appendChild到编辑器 - 不用等全部节点建完再插，而是“建一批、插一批”，让用户更快看到内容，也避免长任务警告
- 切片逻辑必须在 rAF 回调外完成（如提前算好索引范围），否则 rAF 内部做数组切片反而增加开销
- 注意 fragment 插入后自动清空，不能复用同一个变量——每帧都调用一次
document.createDocumentFragment()
