重绘和回流是必须优化的性能瓶颈，同步布局查询（如offsettop、getboundingclientrect、getcomputedstyle）会强制触发回流；transform和opacity因走合成管线更安全；批量dom操作应使用documentfragment或临时隐藏父容器来合并回流。
重绘和回流不是“要不要优化”的问题，而是“改一行代码就可能触发多次回流”的现实——尤其在循环读写 offsetTop、getBoundingClientRect() 或频繁操作内联样式时，性能会断崖式下跌。
哪些操作会强制触发回流？
只要浏览器需要立刻返回准确的几何信息，它就必须立刻执行布局计算。这类“同步布局查询”是回流最隐蔽的入口。
-
offsetTop、offsetLeft、offsetWidth、offsetHeight -
scrollTop、scrollLeft、scrollWidth、scrollHeight -
clientTop、clientLeft、clientWidth、clientHeight -
getBoundingClientRect()、getComputedStyle()（哪怕只读）
注意：getComputedStyle() 即使只是读取 color，也会触发回流——因为浏览器无法预判你下一步是否要改布局属性，只能先清空样式队列、强制 layout。
为什么用 transform 和 opacity 更安全？
这两个属性被浏览器归类为“合成层属性”，修改它们不会触发布局计算，也不会影响其他元素的位置，只走合成（compositing）管线。
-
transform: translateX(10px)≠left: 10px：后者改的是文档流位置，必然回流；前者只是图层位移，GPU 直接处理 -
opacity: 0.5≠visibility: hidden：后者虽不重绘，但保留占位，某些场景下仍参与 layout；前者完全交由合成器控制，且支持硬件加速 - 单独加
will-change: transform并不能自动优化，它只是提示浏览器“这个元素可能会动”，提前分配图层；滥用反而增加内存开销
批量 DOM 修改怎么避免反复回流？
每次向 document.body 追加一个新节点，都是一次独立回流。100 次追加 = 100 次回流 + 100 次重绘。必须把“写操作”集中到一次提交。
- 用
document.createDocumentFragment()缓存所有新节点，最后一次性appendChild() - 临时设置父容器
style.display = 'none'，操作完再恢复——注意：这本身会触发一次回流（隐藏）+ 一次回流（显示），适合中等规模操作 - 改 class 而非 style：把
width、height、margin等全写进 CSS 类，JS 只负责element.className = 'active'，确保所有几何变更合并为一次回流
别信“浏览器会自动批处理”——它只对同帧内的连续写操作做有限合并；一旦中间夹了读操作（比如你读了一次 offsetTop），队列立刻 flush，前面所有写都白费。
display: none 和 visibility: hidden 的真实代价差异
这不是“显示/隐藏”的语义选择题，而是“是否从渲染树剔除”的底层决策。
-
display: none：元素彻底不在渲染树中 → 删除时触发回流，显示时再次触发回流；但后续任何对该元素的样式读写都不再影响布局 -
visibility: hidden：元素仍在渲染树中，占位不变 → 隐藏/显示都不触发回流，只重绘；但它的offsetTop等值依然可读，容易误入同步布局陷阱
真正容易被忽略的是：display: none 的子元素，其 offsetTop 读取会返回 0 或 NaN，而 visibility: hidden 的子元素仍能返回真实值——这意味着后者在调试或计算逻辑中更“诚实”，但也更危险。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
