是，transition卡顿主因是使用left/top/width等触发重排重绘的属性；应改用transform和opacity，它们走合成层、不阻塞主线程，配合正确will-change时机与多属性显式声明可保障60fps流畅动画。
transition卡顿是不是用了left/top/width这些属性？
绝大多数“transition不流畅”的问题，根源不是时间设太长，而是动了不该动的属性。浏览器对left、top、width、height、background-color这类属性做过渡时，每帧都得重新计算布局（Layout）和绘制（Paint），直接拖垮帧率。
真正能稳定跑满60fps的只有两个组合：transform（含translateX、scale、rotate等）和opacity。它们走的是合成层（Compositor Thread），不经过主线程重排重绘。
- 错误写法：
.box { transition: left 0.3s; } .box.active { left: 100px; } - 正确写法：
.box { transition: transform 0.3s; } .box.active { transform: translateX(100px); } - 如果只是想“显隐”，别用
visibility或display切换，改用opacity+pointer-events: none控制交互
为什么加了will-change: transform还是掉帧？
will-change不是开关，是提示。它告诉浏览器“这个元素接下来要动了”，让渲染引擎提前分配合成层——但前提是：你得在动画开始前1–2帧设置，且结束后立刻移除。长期挂着will-change: transform，反而会吃GPU内存、拖慢初始渲染。
- 推荐做法：用
animationstart或transitionrun事件加，animationend/transitionend事件移除 - 避免写
will-change: all或对body、header这种大容器设置 - 老版本 Safari/Android WebView 可配合
transform: translateZ(0)强制升层，现代浏览器中效果已弱化，但留着无害
多个transition同时生效，为什么有些没反应？
transition是按属性名匹配的，不是覆盖式生效。比如只写了transition: transform 0.3s，但hover时同时改了transform和opacity，那opacity的变化就不会有过渡效果。
立即学习“前端免费学习笔记（深入）”；
- 必须显式声明所有要过渡的属性：
transition: transform 0.3s, opacity 0.3s; - 别依赖简写
transition: all 0.3s——它会让所有可变属性都参与过渡，包括你根本没打算动的box-shadow或border-radius，反而增加开销 - 初始值未声明会导致跳变：如果
.box没设transform: translateX(0)，直接:hover加translateX(20px)，第一帧就会“闪一下”
怎么确认真正在掉帧，而不是错觉？
别靠肉眼判断“好像卡”。打开 Chrome DevTools → Rendering 面板，勾选两项：
-
FPS meter：看顶部绿色柱状图是否稳定在60，低于50且频繁断续就是真实掉帧 -
Paint flashing：动画区域外大面积高亮，说明重绘失控；只在动画元素上小范围闪烁才正常 - 进
Performance面板录制操作，看火焰图里Layout或Update Layer Tree占比是否超过15%——高了就说明transform没真正走合成层
复杂交互动画里最容易被忽略的一点：JS读取offsetTop、getBoundingClientRect()这类布局信息，哪怕只读一次，也会强制浏览器同步刷新样式并触发布局，打断正在跑的transition。这类读写必须成对出现，或全部移到requestAnimationFrame回调里批量处理。
