直接循环appendChild会触发多次重排，因每次操作真实DOM节点都可能强制浏览器同步计算布局，尤其读取offsetHeight等布局信息时更易引发强制重排，N次操作即N次重排，性能显著下降。
为什么直接循环 appendChild 会触发多次重排
每次对真实 DOM 节点调用 appendChild、insertBefore 或修改其子节点时，浏览器可能立即计算布局（尤其是当读取了 offsetHeight、getBoundingClientRect() 等布局信息后），导致强制同步重排。循环中反复操作真实节点，等于把 N 次重排“摊开”执行，性能明显下降。
常见错误现象：for (let i = 0; i 在容器已有样式或兄弟元素时，可能每轮都触发重排 —— 尤其在低版本 Chrome 或 Safari 中更明显。
- 真实 DOM 插入是“有副作用”的，浏览器无法批量优化
- 即使容器当前
display: none，部分浏览器仍会为每个插入做最小 layout 计算 -
documentFragment是离线节点，不绑定 document，插入/移动它内部子节点完全不触发重排
createDocumentFragment 的正确用法：只插一次真实 DOM
核心原则：所有新增节点先挂到 document.createDocumentFragment() 上，最后统一 appendChild 到目标容器。这样真实 DOM 只变更一次，浏览器只需一次重排（甚至可能跳过，如果插入后未立即读取布局）。
实操建议：
- 不要把
fragment当作长期缓存对象复用（它没有父节点，但多次appendChild(fragment)后会清空内容） - 避免在 fragment 上调用
querySelector—— 它不参与 CSS 选择器匹配，查不到后代元素（除非已插入 document） - 如果要批量更新现有节点（比如替换文本、改 class），优先用
textContent和className等属性，而非删了再重建 fragment
简单示例：
const fragment = document.createDocumentFragment();
for (let i = 0; i < 100; i++) {
const li = document.createElement('li');
li.textContent = `Item ${i}`;
fragment.appendChild(li); // ✅ 离线操作
}
container.appendChild(fragment); // ✅ 仅此处触发一次重排
和 innerHTML 对比：什么时候该选 fragment
innerHTML 看似更简洁，但它有隐式风险：字符串拼接易 XSS、解析 HTML 成本高、无法复用已有 DOM 节点引用、且某些场景下仍会触发中间重排（如设置 innerHTML 前刚读取过布局）。
推荐用 documentFragment 的场景：
- 需要创建并保留对每个新节点的引用（比如后续绑定事件、动态修改）
- 插入内容含大量自定义元素（
<my-button></my-button>）或需兼容 Web Components v0/v1 生命周期 - 已有节点需移动而非复制（
fragment.appendChild(existingNode)是剪切操作） - 服务端返回的是 JSON 数据而非 HTML 字符串
反例：纯静态列表渲染且无交互需求，innerHTML 通常更快，无需硬套 fragment。
容易被忽略的细节：fragment 不是万能加速器
fragment 只解决“插入频次”问题，不减少单次插入的计算量。如果插入的节点本身带复杂样式、大量嵌套或触发 will-change，重排成本仍在；它只是把成本从 N 次压成 1 次。
真正影响性能的常被忽视点：
- 插入前若存在强制同步布局（如刚调用过
container.offsetHeight），哪怕用 fragment，第一次appendChild仍会重排 - fragment 本身不能被
querySelector查找，调试时别试图用fragment.querySelector('li') - 在 Shadow DOM 中使用时，需确保 fragment 创建于同一 realm（跨 iframe 时注意
iframe.contentDocument.createDocumentFragment()）
最稳妥的做法：插入前清空 layout 读取缓存（比如加个 void 0 或把读取逻辑移到插入之后），再用 fragment 批量上树。
