DocumentFragment能压住重排，是因为它不属真实DOM树，所有操作在内存中进行，不触发布局计算；仅最后append到真实DOM时才一次性完成整个子树的布局，将N次重排压缩为1次。
DocumentFragment 为什么能压住重排，而不是“更快”
很多人以为 DocumentFragment 是因为“JS 执行快”才提升性能，其实它根本没加速 JS，而是绕开了浏览器渲染流水线的中间环节。真实机制是：所有节点在 fragment 内增删、移动、修改属性，都不会触发 layout 计算；只有最后调用 container.appendChild(fragment) 那一刻，浏览器才一次性计算整个子树的布局和绘制。这意味着 100 次 appendChild 原本可能引发 100 次潜在重排，现在只算 1 次。
常见错误现象：在循环里反复对真实 DOM 调用 appendChild，列表滚动卡顿、CPU 占用飙升；用 innerHTML += 替代 fragment，结果每次拼接都导致旧内容全量解析 + 重建 + 回流，复杂度从 O(n) 变成 O(n²)。
-
DocumentFragment不支持querySelector或直接绑定事件监听器（它还没挂载），但可配合事件委托安全使用 - fragment 插入后自动清空，不可复用；多批操作必须每次新建一个
- 在线运行环境（如 CodePen、沙箱 iframe）中尤其敏感——主线程被长循环阻塞时，用户输入响应会明显延迟
如何安全复用 fragment 构建含 HTML 字符串的节点
实际业务中常需插入后端返回或 Markdown 渲染出的 HTML 片段，但 DocumentFragment 本身不支持 innerHTML。硬写 frag.innerHTML = htmlString 会静默失败，且存在 XSS 和结构错乱风险（比如 <tr> 直接塞进 fragment 后再 append 到 <table>，浏览器会自动丢弃）。
正确做法是借临时容器解析：
立即学习“前端免费学习笔记（深入）”；
const temp = document.createElement('div');
temp.innerHTML = htmlString;
while (temp.firstChild) {
frag.appendChild(temp.firstChild);
}
注意三点：
- 若字符串含表格行（
<tr>）、列表项（<li>）等上下文敏感标签，必须先 append 到对应父容器（如<tbody>、<ul>），再把该父容器移入 fragment - 临时
div的innerHTML解析结果不含事件监听器，也不执行内联脚本，比直接eval安全得多 - 不要省略
while (temp.firstChild)循环——直接frag.appendChild(temp)会把整个div当作子节点，而非其子元素
fragment + 池化节点，才是大屏列表的标配组合
仅靠 DocumentFragment 解决不了高频滚动场景下的内存抖动问题。例如每秒刷新 10 次、每次更新 200 个卡片，哪怕用 fragment 批量插入，仍等效每秒创建/销毁 2000 个节点。低端设备上 layout 时间可能飙升 3–5 倍，usedJSHeapSize 持续爬升，Memory 面板里出现大量 Detached DOM tree。
真正有效的方案是：用 DocumentFragment 批量组装，但节点来源不是 createElement，而是来自预分配的节点池。核心逻辑如下：
- 所有节点初始化时必须带唯一
dataset.id，且结构固定（如子元素 class 名、层级不可变） - 节点滚出视口时调用
recycleNode(el)，设el.style.display = 'none'并存入Map，不调用removeChild - 新数据来时优先查池：
nodePool.get(id)，存在则复用并批量更新textContent、dataset、src等字段 -
recover()必须清空textContent和innerHTML，否则残留内容会在下次显示时意外出现
为什么 Memory 面板里 JS Heap 不回落，不等于 fragment 写错了
看到 performance.memory.usedJSHeapSize 持续上涨，第一反应不该是“fragment 没用好”，而应先排除三类泄漏根源：Detached DOM、未解绑事件监听器、闭包强引用。HTML 本身不分配内存，浏览器构建的 DOM 树、CSSOM、Render 树及关联 JS 对象才是主体。
实操验证步骤：
- 打开 DevTools → Memory → Record allocation timeline，执行几次列表刷新，停止后观察曲线是否每次操作后都跳升且不回落
- 拍堆快照前先点
Collect garbage，再对比 “Objects allocated between snapshots”，重点看HTMLDivElement、Closure、EventListener是否与你插入/绑定的数量严格对应 - 运行
getEventListeners(document.querySelector('.item-btn'))，若返回数组长度 > 1，说明事件重复绑定且未解绑
fragment 是优化手段，不是内存泄漏的“解药”。它减少重排，但不改变节点生命周期。真正决定内存能否回收的，是你有没有在节点移除前切断 JS 引用、清空定时器、解绑事件——这些动作和 fragment 无关，却决定最终能否 GC。
