立刻触发重排且无法合并的操作包括：offsetwidth、offsetheight、getboundingclientrect()、getcomputedstyle()（哪怕只读color），均强制同步flush样式队列；常见陷阱如for循环中混用style修改与offsettop读取，或访问live collection的length，均导致layout thrashing。
哪些 JS 操作会立刻触发重排，且无法被浏览器合并？
只要调用 offsetWidth、offsetHeight、getBoundingClientRect()、getComputedStyle()（哪怕只读 color），浏览器就必须立刻 flush 排队中的样式变更，强制执行一次完整 layout。这不是“可能”触发，而是同步阻塞行为。
- 常见陷阱：在
for循环里写el.style.left = i + 'px'; console.log(el.offsetTop);—— 每轮都触发一次重排 -
document.getElementsByTagName('div')是 live collection，每次访问.length或遍历[i]都可能回滚样式队列 -
getComputedStyle(el).width和el.offsetWidth效果完全等价，别以为“只读不写就安全”
为什么“读-写分离”比加节流更关键？
根本矛盾不在调用频率，而在链式依赖：浏览器能合并 100 次 el.style.width = '200px'，但只要中间插一句 el.offsetWidth，前面所有待生效样式就被强制结算；后续再改，又触发新一轮 layout。
- 错误模式：
读→写→读→写→…，形成 layout thrashing - 正确做法：先批量读（如一次
getBoundingClientRect()取 top/height/width），再批量写（如用el.style.cssText或classList.add()） - 对高频变动元素，优先用
transform+will-change: transform，绕过 layout 计算
DOM 插入类操作如何避免隐式重排放大？
DocumentFragment 只对插入有效——往它里面 append 元素、改 class、设 style 都不触发重排，但 fragment.appendChild() 挂到真实 DOM 的那一刻，才是唯一重排点。
- 适合场景：动态生成整块列表、表格、卡片组，且后续不再单独更新子项
- 不适合场景：需要频繁增删单个子节点，或插入后立即读取
offsetHeight - 替代方案：对需局部更新的区域，用
display: contents扁平化结构（注意可访问性损失）
HTML 标签嵌套错误为何会放大重排范围？
浏览器解析时自动修正非法嵌套（如 <p></p>
<div>hello</div>
-
<ol><p>Item</p></ol>→ 被拆成两个独立<ol></ol>+ 中间孤立<p></p>，原本一次 layout 变成三次 <table> 内未用 <code><tbody> 包裹 <code><tr> → 浏览器补全匿名表格对象，破坏 <code>table-layout: fixed列宽锁定- 用 DevTools 的 Layers 面板观察小尺寸、边界重叠的合成层，往往是嵌套修正引发的渲染子树碎片化信号 真正卡顿的根源，往往不是你写了多少次
style.left，而是你在哪一刻打断了浏览器本可合并的样式队列。一个 offsetTop 调用，就足以让之前所有优化失效。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
