document.createdocumentfragment 能压住高频 dom 操作性能抖动，是因为它避免了多次 layout 计算：往 fragment 插入 100 个节点零开销，仅最后 appendchild 时一次性完成整棵子树布局。
document.createDocumentFragment 为什么能压住高频 DOM 操作的性能抖动
它不是让 JS 执行更快，而是让浏览器少做 99 次 layout 计算。每次对已挂载元素调用 appendChild，只要父容器有布局依赖（比如 float、flex、position: relative），浏览器就可能立即触发样式计算 + 几何测量。100 次插入 ≈ 100 次潜在重排，主线程直接卡死。
document.createDocumentFragment() 返回的是一个不挂载、无 ownerDocument、不参与渲染管线的轻量对象。往里面塞 100 个 li，全程零 layout、零 paint、零 computedStyle 缓存开销——直到你调用 container.appendChild(frag) 那一刻，浏览器才一次性完成整个子树的布局计算。
关键点在于：fragment 插入后自动清空，不可复用；每次批量操作都必须新建一个。
高频插入场景下 fragment 和 innerHTML 的取舍边界
别只看“谁快”，要看“谁可控”。字符串拼接 innerHTML 在纯静态内容场景下确实更快，但它会抹掉已有事件监听器、重置 <input> 的 value、清空 dataset、暴露 XSS 风险——这些代价在高频更新组件里是隐性但致命的。
以下情况必须选 document.createDocumentFragment：
- 节点已存在（如从
template.content.cloneNode(true)克隆而来），需保留原始属性和事件绑定上下文 - 每个新节点要绑定不同事件处理器（比如带
data-id的按钮，回调需闭包捕获索引） - 内容来自用户输入或富文本编辑器输出，需天然防 XSS —— 用
textContent+ fragment 比手写escapeHtml()更可靠 - 目标环境需兼容 IE9（
frag.append()是 IE10+，但frag.appendChild()全版本通吃）
压测中容易被忽略的三个“假优化”陷阱
性能压测常显示 fragment 稳定优于循环 appendChild，但真实业务里卡顿仍频发——问题往往出在 fragment 外围调度逻辑上。
常见漏点：
- 在 fragment 构建前读取任何布局信息（如
el.offsetHeight、getComputedStyle(el).width），哪怕 el 是 display: none，也会强制浏览器 flush style 并提前重排 - 把 fragment 当作“可复用缓存”，重复调用
container.appendChild(frag)—— 第二次起frag已为空，实际没插任何节点，但代码看似执行成功 - 误以为 fragment 支持
querySelector或能直接绑定事件，写出frag.querySelector('button').addEventListener(...)这类无效代码，既不报错也不生效，调试时极难定位
真实高频更新组件中的 fragment 使用节奏
fragment 只解决“插入”这一步，而高频更新本质是“生成 → 更新 → 插入 → 清理”的闭环。漏掉任一环，fragment 就只是个漂亮摆设。
推荐节奏：
- 生成阶段：用
document.createElement或template.content.cloneNode(true)创建节点，避免在循环里反复调用innerHTML - 更新阶段：直接操作节点属性（
node.dataset.id = id、node.textContent = text），不要在 fragment 上做任何 query 或事件绑定 - 插入阶段：仅一次
container.appendChild(frag)，且确保 container 是已挂载的真实 DOM 节点 - 清理阶段：若需替换旧内容，先
container.innerHTML = ''或while(container.firstChild) container.removeChild(container.firstChild)，再插入 fragment —— 别指望 fragment 自动帮你删老节点
最易被忽略的是清理环节：很多组件反复插入却从未清空旧节点，内存占用随时间线性增长，最终 GC 压力反噬主线程。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
