Performance面板中密集的Layout/Paint块表明transition拖垮主线程；需检查transition:all、未提升合成层、同步布局读取及浮动元素等隐性重排触发点。
直接看 Performance 面板里有没有密集的 Layout / Paint 块——有，说明 transition 正在拖垮主线程；没有，问题大概率不在 CSS 过渡上。
用 Chrome Performance 面板定位高开销 transition
打开 DevTools → Performance → 点录制（●），复现疑似卡顿的操作（比如快速 hover 一排按钮、滚动时菜单展开），停止后看火焰图。
- 帧时间超过
16ms且底部堆满红色 Layout / Paint 事件，就是重排/重绘在吃 CPU - 找到对应元素，右键 → Reveal in Elements panel，再切到 Styles 面板，搜
transition - 重点检查是否写了
transition: all、transition: width 0.3s或transition: left 0.2s这类高成本组合 - 如果某次 hover 后
Recalculate Style时间异常长，大概率是 class 切换触发了大量样式重算，而非动画本身
确认动画是否真的走 GPU 合成层
光写 transform 不等于就加速了。得亲眼看到绿色边框才算数。
- DevTools → Rendering → 勾选
Layer Borders：有绿色边框的元素才被提升为独立合成层 - 没绿框？检查父容器是否加了
overflow: hidden、filter: blur(1px)或backdrop-filter——这些会抑制子元素提层 - 动画中同时用了
box-shadow（尤其动态变化的）或filter，也可能让图层合并失败，退回到 CPU 渲染 - 移动端 Safari 对
will-change: transform处理不稳定，有时反而更卡；可改用transform: translateZ(0)回退，但别和will-change混用
为什么改了 transform 还卡？查隐性重排触发点
即使 transition-property 写对了，JS 里偷偷干的几件事也能让 GPU 加速失效。
立即学习“前端免费学习笔记（深入）”；
- 动画进行中调用了
getBoundingClientRect()、offsetTop、clientWidth等同步读取布局的 API，会强制触发回流（forced synchronous layout） - 初始状态用
left: 0，hover 时却用transform: translateX(20px)——混合写法会让浏览器不敢优化，仍按旧路径走 - 伪元素（
::after）用width做下划线动画？必须统一改成transform: scaleX() - 浮动元素（
float）上加 transition 必抖，第一步不是优化，是先移除float，改用display: flex或position: absolute
真正难处理的不是怎么写 transition，而是判断“这里到底需不需要动”。很多卡顿来自过渡被无意识启用——比如表格行 hover、页脚文字颜色变化、静态 banner 的 opacity 微调。动效的价值是引导注意力，不是填满每一处样式变更。
