结论：不是不一致，而是WebKit对cubic-bezier()解析更严格；Chrome静默修正越界值，Safari可能降级为ease或忽略声明；cubic-bezier(0.42,0,0.58,1)是安全起点，四参数均在[0,1]内，全浏览器一致。
Transition-timing-function 在 Chrome 和 Safari 中表现不一致？
直接说结论：不是“不一致”，而是 WebKit（Safari）对 cubic-bezier() 的数值解析更严格，尤其当控制点坐标超出 [0, 1] 范围时，Chrome（Blink）会静默修正，Safari 则可能降级为 ease 或直接忽略整条声明。这不是 bug，是规范允许的实现差异——CSS Easing Functions Level 1 明确指出：超出 [0, 1] 的 y 坐标（即 cubic-bezier(0.25, 1.5, 0.75, -0.5) 中的 1.5 和 -0.5）属于“无效值”，用户代理可自行处理。
为什么 cubic-bezier(0.42, 0, 0.58, 1) 是安全的起点
这个值是 ease-in-out 的标准等效写法，所有主流内核都 100% 支持，且完全落在合法区间内（x 和 y 均 ∈ [0, 1]）。它能避开绝大多数兼容性陷阱，适合需要精确控制又不想踩坑的场景。
- 用
cubic-bezier(0.42, 0, 0.58, 1)替代ease-in-out，可确保动画曲线在 Safari、Chrome、Firefox 中完全一致 - 若需自定义缓动，优先将四个参数全部约束在 [0, 1] 内，例如
cubic-bezier(0.3, 0.1, 0.7, 0.9) - 不要依赖
cubic-bezier(0.25, 1.5, 0.75, -0.5)这类“弹性”曲线在 Safari 中生效——它在 Safari 16+ 才开始部分支持，旧版直接失效
如何检测并 fallback 非标准 cubic-bezier
纯 CSS 没有运行时检测机制，但可通过 JavaScript 验证后动态加 class：
const isValidCubic = (a, b, c, d) => {
return [a, b, c, d].every(v => typeof v === 'number' && v >= 0 && v <= 1);
};
if (isValidCubic(0.3, 0.1, 0.7, 0.9)) {
element.classList.add('has-smooth-ease');
} else {
element.classList.add('has-fallback-ease');
}
对应 CSS 中分别定义：
立即学习“前端免费学习笔记（深入）”；
.has-smooth-ease { transition-timing-function: cubic-bezier(0.3, 0.1, 0.7, 0.9); }
.has-fallback-ease { transition-timing-function: ease; }
- 注意：不能用
getComputedStyle(el).transitionTimingFunction反查是否生效——它返回原始字符串，不反映实际计算结果 - 服务端渲染或构建时校验更可靠：把非 [0,1] 的
cubic-bezier自动转成ease或 warn 提示
PostCSS 插件能自动化处理吗？
可以，但需谨慎。插件如 postcss-cubic-bezier 能把超限值 clamp 到 [0,1]，但它会改变动画意图——cubic-bezier(0.25, 1.8, 0.75, -0.3) 被 clamp 成 cubic-bezier(0.25, 1, 0.75, 0) 后，已不是原设计的“先冲高再回弹”效果。
- 推荐仅对明确标注为“兼容模式”的样式启用 clamp，例如类名含
-legacy - 开发阶段用 ESLint 规则（如
stylelint-csstree-validator）提前拦截非法值，比 runtime fallback 更早发现问题 - 真正需要非标准贝塞尔曲线时，改用
@keyframes+animation-timing-function，其兼容性略好于transition场景
最易被忽略的一点：transition 的 timing function 是逐属性生效的，如果同时过渡 transform 和 opacity，而只给其中一个写了 cubic-bezier，另一个会回退到默认 ease——这种隐式不一致，在多内核下更容易暴露为节奏错位。
