应优先使用transform和opacity替代width、height、top、left、margin、padding、display等触发重排的属性，批量变更用className而非style，resize/scroll事件需节流并配合requestAnimationFrame，读取布局信息须集中前置、写操作统一后置。
哪些 CSS 属性会触发重排（reflow）
重排是性能杀手，因为它强制浏览器重新计算整个布局树。只要改了 width、height、margin、padding、top、left、right、bottom、display、font-size 等属性，就大概率触发重排。
响应式中尤其危险的是在 @media 规则里动态改这些值——比如用 max-width: 768px 切换时把 .sidebar { width: 200px } 改成 width: 100%，浏览器必须立刻重算所有相关元素的位置和尺寸。
- 避免用
width/height控制响应式显隐，改用transform: scaleX(0)+opacity: 0 - 不要在
resize或matchMedia回调里直接设element.style.marginTop，它会立刻重排 -
display: none虽然不触发重排，但切换时会引发 layout thrashing，只用于低频、非动效场景
哪些属性看似“动效友好”实则暗藏高开销
transform 和 opacity 是安全的，但加了修饰后可能翻车：
-
will-change: transform在老设备或未清理时，会持续占用图层内存，动画结束必须手动移除 -
transform: translateZ(0)或translate3d(0,0,0)强制升层，但若页面有几十个同类元素，GPU 显存会溢出 -
filter: blur(3px)或多层box-shadow在中低端 Android WebView 中几乎卡死，且无法被合成器线程接管 -
clip-path（尤其配合path()）在 Safari 15.6 前基本无硬件加速，纯 CPU 渲染
媒体查询里最容易被忽略的性能陷阱
媒体查询本身不慢，但它激活的样式组合才是问题源头：
立即学习“前端免费学习笔记（深入）”；
- 嵌套
@media（如@media (min-width: 768px) { @media (prefers-reduced-motion) { ... } }）在旧内核中解析失败或延迟生效 - 用
calc()配合vw/vmin动态算font-size，每次视口变化都触发重排+重绘 - 在多个断点中重复声明
will-change: opacity，导致同一元素被多次提升图层，最终图层数量失控 -
background: linear-gradient(...)配合background-size: cover，在 iOS Safari 14.5 以下会强制重绘整块背景区域
transition 写法不当如何放大问题
transition: all 0.3s 是最常见也最危险的写法：
- 它会让浏览器监听所有可动画属性，包括你根本没改的
color、border-color、box-shadow - 一旦 JS 后续修改了
padding，哪怕只是临时加个 class，也会触发重排——而你本意只想过渡transform - Chrome DevTools 的 “Paint flashing” 一开，就能看到大片黄色，说明你在重绘不该重绘的东西
- 正确写法是显式声明：
transition: transform 0.25s ease, opacity 0.25s ease，一个字都不能多
@media 改了 width，同时 transition: all 监听了它，再配上一个未清理的 will-change —— 三者合谋，帧率立刻掉到 30fps 以下。 
