CSS过渡不流畅？调整持续时间优化效果

CSS过渡动画不流畅往往并非缓动曲线不够精致，而是根源性地触发了浏览器重排重绘、硬件加速未开启或过渡声明被意外覆盖；真正有效的优化在于：将transition-duration设为至少0.2s（避免毫秒单位兼容问题）、严格限定过渡属性为transform和opacity、用translateZ(0)或will-change主动启用GPU合成层，并选用更自然的cubic-bezier(.25,.46,.45,.94)替代默认ease——这些底层渲染机制的调整，比反复调试贝塞尔曲线更能立竿见影地解决卡顿，让交互真正丝滑可信。

过渡动画卡顿是因为 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，防止浏览器合并样式计算导致过渡丢失

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《CSS过渡不流畅？调整持续时间优化效果》文章吧，也可关注golang学习网公众号了解相关技术文章。