立刻触发重排且无法合并的操作包括：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 的那一刻，才是唯一重排点。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 适合场景：动态生成整块列表、表格、卡片组，且后续不再单独更新子项
- 不适合场景：需要频繁增删单个子节点，或插入后立即读取
offsetHeight - 替代方案：对需局部更新的区域，用
display: contents扁平化结构（注意可访问性损失）
HTML 标签嵌套错误为何会放大重排范围？
浏览器解析时自动修正非法嵌套（如 <p><div>hello</div></p>），这个过程本身就会生成额外节点、重算样式、拉长祖先链，导致重排次数翻倍甚至指数级扩散。
立即学习“前端免费学习笔记（深入）”；
-
<ol><p>Item</p></ol>→ 被拆成两个独立<ol>+ 中间孤立<p>，原本一次 layout 变成三次 -
<table>内未用<tbody>包裹<tr>→ 浏览器补全匿名表格对象，破坏table-layout: fixed列宽锁定 - 用 DevTools 的 Layers 面板观察小尺寸、边界重叠的合成层，往往是嵌套修正引发的渲染子树碎片化信号
style.left，而是你在哪一刻打断了浏览器本可合并的样式队列。一个 offsetTop 调用，就足以让之前所有优化失效。 
