是，卡顿主因是对非合成属性（如left、background-color）做transition；仅transform和opacity可走GPU合成层，避免重排重绘。
transition 动画卡顿，是不是用了 transform 和 opacity 以外的属性？
绝大多数卡顿都源于对非合成属性做过渡——比如直接 transition: left 0.3s 或 transition: background-color 0.3s。浏览器会强制触发 Layout → Paint → Composite 全流程，帧率掉得明显。
真正能走 GPU 合成层、避免重排重绘的只有这几个属性：transform（含 translate、scale、rotate）、opacity。其他都算“高成本动画属性”。
- 用
left/top移动元素？改用transform: translateX(10px) - 想渐变背景色？不如用半透明遮罩层叠在纯色背景上，靠
opacity控制显隐 -
width/height变化会触发布局，优先考虑transform: scaleX()或缩放伪元素
keyframes 动画一卡一卡，是不是没加 will-change 或没启用硬件加速？
will-change 不是万能开关，但它能提前告诉浏览器：“这个元素接下来要动了”，让渲染引擎提前分配合成层。不加不一定出错，但复杂动画下容易掉帧。
但别滥用：will-change: transform 只应在动画开始前加，动画结束及时移除（或用脚本控制），否则长期占用 GPU 内存反而拖慢整体性能。
立即学习“前端免费学习笔记（深入）”；
- 只对真正需要动画的元素设置，比如模态框、滑动菜单等高频交互区域
- 避免写
will-change: all或对整个body设置 - 配合
transform: translateZ(0)或transform: translate3d(0, 0, 0)强制启用 GPU 加速（现代浏览器中效果已弱化，但老版本 Chrome/Safari 仍有效）
transition 和 @keyframes 混用时，为什么动画中途跳变或失效？
两者共存时存在优先级和覆盖规则：CSS 动画（@keyframes）默认会覆盖 transition 的中间状态；但如果 transition 属性名与 keyframes 中正在修改的属性完全一致，且 transition 正在运行中，就可能产生冲突。
最稳妥的做法是「场景隔离」：用 transition 做简单状态切换（悬停、点击反馈），用 @keyframes 做复杂时序动画（加载旋转、路径运动）。
- 不要同时给同一个元素的
transform既设transition: transform 0.2s，又用animation: spin 1s infinite - 若必须叠加，用
animation-fill-mode: forwards+ 显式重置初始态，再靠 JS 控制 class 切换时机 - 检查
animation-play-state是否被意外设为paused，这会导致看似“卡住”
移动端 touch 交互后动画延迟，是不是没有开启 passive event 或忽略了 touch-action？
iOS Safari 和 Android Chrome 在监听 touchstart 后，默认会等待 300ms 确认是否为双击缩放，期间会阻塞主线程，导致后续 transition 延迟启动。
根本解法不是加 touch-action: manipulation（它只禁双击缩放），而是确保 CSS 动画本身不依赖 JS 触发时机——比如把 hover 改成 class 切换，用 :active 配合 transition 实现即时反馈。
-
touch-action: none要慎用，它会禁掉所有原生滚动/缩放，影响可访问性 - 避免在
touchend回调里才加动画 class；改用pointerdown+pointerup并设passive: true - 安卓上部分 WebView 对
transform的子像素渲染支持差，可加transform: translateZ(0.001px)微调对齐
动画是否流畅，最终看的是合成层是否稳定、主线程是否被 JS 或样式计算拖住。很多“优化技巧”只是表象，真正要盯住的是 DevTools 的 Rendering 面板里有没有频繁的 Layout / Paint 标记，以及 FPS 曲线是否持续在 58–60 之间波动。
