直接循环appendChild会卡顿浏览器，因为每次插入都触发重排重绘，造成大量无效布局计算；DocumentFragment通过延迟至一次性插入来避免中间状态的冗余计算。
为什么直接循环 appendChild 会卡顿
浏览器每执行一次 appendChild，都可能触发重排（reflow）和重绘（repaint），尤其在循环插入成百上千个节点时，DOM 树频繁变更，渲染引擎压力陡增。更关键的是，每次插入都会让浏览器尝试“即时更新布局”，哪怕后续还有几十次插入——这些中间状态全是无效计算。
常见现象：for 循环里反复调用 parent.appendChild(child)，页面明显卡顿、滚动掉帧，Performance 面板里看到大量 Layout 任务堆积。
document.createDocumentFragment 的真实作用不是“加速”，而是“延迟布局计算”
它本质是一个轻量级的、不挂载到文档中的 DOM 容器。所有对它的操作（appendChild、append 等）都不会触发任何布局计算，浏览器只做内存节点管理。只有当你把它一次性插入真实 DOM 时，才触发一次布局。
实操建议：
- 用
const frag = document.createDocumentFragment()创建片段，不要复用已插入过的 fragment（它插入后自动清空） - 把所有要插入的节点先
frag.appendChild(node)或frag.append(...nodes)进去 - 最后只调用一次
realParent.appendChild(frag)—— 此时 fragment 中的子节点会被“迁移”过去，fragment 自身变为空 - 注意：fragment 不支持
querySelector、innerHTML等方法，它只是容器，不是完整文档上下文
对比原生 innerHTML 批量插入的适用边界
innerHTML 看似更简单，但它涉及 HTML 字符串解析、实体转义、潜在 XSS 风险，且无法复用已有节点引用（比如你手头有一堆已创建好的 li 元素，innerHTML 强制你转成字符串再 parse，浪费性能）。
选 DocumentFragment 更合适的情况：
- 你已有现成的 DOM 节点（比如通过
document.createElement创建或从别处克隆而来） - 需要控制节点插入顺序、保留事件监听器绑定（fragment 不影响节点本身）
- 插入逻辑复杂，含条件分支、动态属性设置，用字符串拼接易出错
- 目标环境需兼容 IE9+（
DocumentFragment支持良好；append方法需 IE10+，可用appendChild兼容）
一个典型但容易被忽略的坑：DocumentFragment 不是“万能缓存”
有人误以为创建一次 fragment 就能反复使用，结果发现第二次插入没内容。这是因为 fragment 插入后内部节点被移走，fragment 变为空。每次批量插入前都必须新建：
function batchAppend(parent, nodes) {
const frag = document.createDocumentFragment(); // ✅ 每次都要 new
nodes.forEach(node => frag.appendChild(node));
parent.appendChild(frag); // ✅ 仅此一次真实 DOM 操作
}
另一个坑：在 fragment 上监听事件没意义，它不参与事件冒泡链；所有事件仍得绑定在最终挂载后的实际父节点或委托处理。
真正省下的不是“JS 执行时间”，而是浏览器被迫做的无意义布局计算次数——这点在长列表、实时日志、图表节点生成等场景下，差异肉眼可见。
