最消耗性能的布局属性是width、height、top、left、right、bottom、margin、padding、font-size、border、display等，因每次修改都强制浏览器重新计算整个布局树；而transform和opacity仅触发合成，不重排不重绘，是高性能动画的唯一可靠选择。
最消耗性能的布局属性是那些会强制触发重排（reflow）的属性，包括 width、height、top、left、right、bottom、margin、padding、font-size、border、display 和 position（除 fixed 和 sticky 外的变更）。它们不是“慢一点”，而是每次修改都迫使浏览器重新计算整个布局树——在 16ms 一帧的约束下，单次重排就可能超时。
为什么 width / height / margin 等属性一动就卡
这些属性直接参与盒模型尺寸与位置计算，浏览器无法只更新一个元素，必须向上遍历父容器、向下检查子元素，确认是否影响其他节点。尤其在以下场景中问题放大：
- 在
scroll或mousemove回调里频繁设置element.style.width = w + 'px' - 用
getComputedStyle()或offsetHeight读取后立刻写样式，造成“强制同步布局” - 父容器设置了
overflow: hidden或transform，但子元素仍改left，导致合成层失效+重排叠加
left / top 动画 vs transform: translate 的真实差异
left 和 transform: translateX() 视觉效果几乎一样，但底层路径完全不同：
-
left: 100px→ 触发 Layout → Paint → Composite（三阶段全走） -
transform: translateX(100px)→ 直接跳到 Composite（仅合成层位移） - 后者不改变文档流，不触发重排，GPU 可批量处理多个元素的位移，主线程压力极小
- 注意：
transform: translateZ(0)不等于自动提层，得用 Chrome DevTools → Rendering → “Layer Borders” 看绿框是否真实出现
哪些“看似无害”的布局操作实际很危险
有些写法容易被忽略，但会在生产环境悄悄拖垮性能：
立即学习“前端免费学习笔记（深入）”；
- 在循环中反复切换
display: none/block：比visibility: hidden重得多，每次都会触发布局移除与重建 - 用
calc()配合百分比动态算width，并在 JS 中高频更新：解析 + 计算 + 布局三重开销 - 给大量列表项加
margin-bottom: 1rem，又用 JS 批量 toggle 类——外边距合并行为会让重排更难预测 - 全局写
* { box-sizing: border-box; }是好习惯，但若配合transition: all，浏览器会为每个属性做过渡准备，哪怕你只改了color
真正要盯住的不是“能不能用”，而是“改这个值会不会让浏览器重新跑 Layout”。只要涉及尺寸、位置、可见性或结构变化，就得默认它贵；而 transform 和 opacity 是目前唯一被所有主流引擎稳定支持的廉价替代路径。
