过渡动画卡顿主因是避开重排重绘，需设≥200ms的transition-duration、仅过渡transform/opacity、用translateZ(0)开启硬件加速、避免transition:all及覆盖失效，并选用合适cubic-bezier缓动曲线。
过渡动画卡顿是因为 transition-duration 太短或单位错用
小于 100ms 的 transition-duration 容易被浏览器舍入或调度不及时，导致视觉上“跳变”而非平滑过渡。常见错误是写成 transition: all .1s（即 100ms），实际应至少设为 .2s（200ms）起手。另外，用毫秒单位（如 150ms）虽合法，但 CSS 规范更倾向秒单位，部分旧版 Safari 对 ms 解析不稳定，统一用 s 更稳妥。
- 避免
transition: all .05s ease;—— 时间太短，人眼无法分辨渐变过程 - 优先写具体属性：比如只过渡
transform和opacity，而不是all，减少重排（reflow）触发 - 确保初始和结束状态的值类型可插值：例如
height: 0→height: 200px会触发布局计算，而transform: scaleY(0)→transform: scaleY(1)是纯合成层操作，更顺滑
ease 不等于“自然”，多数场景该换 cubic-bezier(.25,.46,.45,.94)
默认 ease（即 cubic-bezier(.25, .1, .25, 1)）起始加速太猛、收尾拖沓，在按钮悬停、下拉展开等交互中容易显得“弹跳”。Framer Motion 和苹果设计系统实际常用的是更克制的缓动曲线，接近 cubic-bezier(.25, .46, .45, .94)，它起始柔和、中段线性、收尾有张力但不突兀。
- 用 cubic-bezier.com 可视化调试，拖动控制点实时预览
- 不要在所有过渡里硬套同一曲线：图标旋转适合
linear，模态框淡入适合带轻微回弹的cubic-bezier(.34, 1.56, .64, 1)（需注意超出 [0,1] 的 y 值是允许的） - 慎用
ease-in-out：它在两端都减速，中间过快，长距离位移时易显“飘”
硬件加速没开，transform 和 opacity 也被降级渲染
即使写了 transform: translateX(10px)，如果父容器没形成独立合成层，浏览器仍可能把它当作普通样式处理，导致每帧都重绘（repaint）而非复用 GPU 图层。这不是过渡本身的问题，而是渲染管线没走对路。
- 给触发过渡的元素加
will-change: transform;（仅在需要时加，别全局滥用） - 更稳妥的方式是强制创建合成层：加
transform: translateZ(0);或opacity: .99;（注意不是1，否则优化会被跳过） - 检查 DevTools → Rendering → “Paint flashing”：绿色闪动越少越好；若大面积闪，说明仍在软渲染
动画被 JS 阻塞或 CSS 层叠覆盖，transition 根本没生效
最常被忽略的是：CSS 过渡声明被更高优先级规则覆盖，或者 JS 直接改了 style 内联属性却没清除旧值，导致过渡链断裂。比如用 el.style.left = '100px' 后再切 class，left 内联值会压制 class 里的 transform，过渡直接失效。
立即学习“前端免费学习笔记（深入）”；
- 用 DevTools 的 Elements 面板检查元素最终生效的
transition值，确认没被none覆盖 - JS 控制动画时，优先操作
transform和opacity，避免直接写top/left等触发布局的属性 - 批量状态变更时，用
getComputedStyle(el).transform强制触发重排后再加 class，防止浏览器合并样式计算导致过渡丢失
cubic-bezier，却没发现父容器 overflow: hidden 正在剪裁合成层——那种卡顿，再好的缓动也救不回来。 
