document.appendChild()后页面不立刻更新，是因为浏览器将DOM变更排队至JS调用栈清空后批量渲染，而非API阻塞；DocumentFragment通过内存中批量操作、仅一次性插入，将N次重排压缩为1次，避免中间状态冗余计算。
为什么document.appendChild()之后页面不立刻更新
DOM插入操作本身不阻塞，但浏览器不会在JS执行中途渲染——所有DOM变更会排队，等当前JS调用栈清空后才批量提交并渲染。你看到的“延迟”，其实是浏览器的渲染调度机制，不是DOM API的问题。
常见错误现象：document.body.appendChild(h1)执行后，console.log("DOM操作已提交,但未渲染")立刻输出，但页面上要等循环结束才显示文字。
- 只要JS线程没退出（比如还在for循环里），渲染线程就被锁住，哪怕DOM树已变更
-
offsetHeight、getComputedStyle()这类读取布局的API会强制触发同步重排，进一步拖慢执行 - 单次插入10个节点 vs 逐个插入10次，前者只触发1次重排，后者可能触发10次（尤其在循环中混用读写）
用DocumentFragment做最小粒度批处理
不用框架、不引入虚拟DOM，DocumentFragment是原生最轻量的批处理方案——它不挂载到真实DOM，所有子节点操作都在内存中完成，最后一次性插入。
典型误用：container.appendChild(item)写在循环里；正确做法是先攒进fragment，再append一次。
立即学习“前端免费学习笔记（深入）”；
- fragment本身不触发任何重排或重绘，纯内存操作
- 插入fragment时，浏览器只计算一次布局，而不是每个节点都算一遍
- 注意不要对fragment重复调用
appendChild()，它内部是移动节点而非复制——第二次调用会把节点从fragment里移走 - 如果需要保留原始节点引用，用
cloneNode(true)后再加进fragment
微小更新也要防强制同步刷新
即使只改一个元素的textContent，如果前面刚读过它的offsetTop或clientWidth，浏览器就得立刻重排，把“微小更新”变成高成本操作。
这种读写混合在列表渲染、动画帧内最常见，也是卡顿主因之一。
- 把所有读操作集中到循环前：缓存
item.offsetHeight，别在每次迭代里反复读 - 把所有写操作集中到循环后：先收集变更，再统一应用，避免“读→写→读→写”交错
- 用
requestAnimationFrame()包裹写操作，确保它在下一帧渲染前提交，而不是等JS执行完才交出去 - 避免在事件处理器里直接操作DOM，尤其是高频事件（如scroll、mousemove）——节流+batch update才是解法
async/defer脚本对微更新的实际影响
脚本加载策略不改变DOM更新逻辑，但它决定你何时能安全执行微更新——多数卡顿其实源于脚本执行时机错配，而非更新本身慢。
例如：一个async脚本在<header>还没解析完就执行，document.querySelector("header")必然返回null，后续所有微更新都失败。
-
defer脚本最稳妥：DOM解析完、DOMContentLoaded前执行，保证元素存在 -
type="module"默认等效defer，且支持顶层await，适合等待CSS或数据就绪后再批量更新 - 内联脚本加
async或defer无效，浏览器直接忽略——想安全操作DOM，必须放目标元素之后，或包在DOMContentLoaded里 - 动态插入的脚本（
document.createElement("script")）默认同步阻塞，要手动设async = true
innerText赋值可能触发重排，如果它发生在强制同步刷新链路里；而100次节点插入用DocumentFragment封装，反而比1次裸操作更轻。关键不在“量”，而在“时机”和“上下文”。 
