应只对 transform 和 opacity 使用 CSS 动画，因其可被提升为独立图层实现硬件加速；避免 left、width 等触发布局的属性，Safari 对非合成属性容忍度低易卡顿；需显式声明 animation-duration，确保 @keyframes 至少含 0% 和 100%，并用浏览器渲染面板验证合成层是否生效。
动画在 Chrome 正常，Safari 卡顿或不触发怎么办
根本原因常是 Safari 对 transform 和 opacity 以外的属性做动画时强制走主线程（比如直接 animating left、width 或 background-color），而 Chrome 可能仍尝试硬件加速。Safari 尤其对非合成属性（non-composited properties）的动画容忍度低，容易掉帧甚至跳过关键帧。
- 只对
transform（含translateX、scale、rotate）和opacity做 CSS 动画，这两者可被提升为独立图层，绕过主线程重排重绘 - 避免用
top/left替代transform: translate()；即使数值相同，前者会频繁触发 layout - 给动画元素显式添加
will-change: transform（仅在必要时，且记得动画结束后移除或设为auto） - 检查是否启用了
prefers-reduced-motion，Safari 默认更严格响应此媒体查询，可能直接禁用动画
Firefox 不执行 @keyframes 或动画突然中断
Firefox 对未声明 animation-duration 或 animation-name 的规则更敏感，也更容易因语法小瑕疵（如多一个逗号、单位缺失）而整条 @keyframes 失效——它不会像 Chrome 那样“尽力修复”。
- 确保每个
@keyframes块内至少有两个有效帧（0%和100%），且无重复帧名或非法百分比（如50.5%在旧版 Firefox 中可能被忽略） -
animation简写中若省略animation-duration，Firefox 会认为该动画无效（值为0s），必须显式写出，例如：animation: slide 0.3s ease-in-out - 避免在
@keyframes中使用尚未被广泛支持的函数，如color-mix()或hwb()，Firefox 可能直接跳过整个帧定义
如何检测浏览器是否真正启用了硬件加速
不能只看“动起来了”，要看是否真在合成层运行。Chrome DevTools 的 Layers 面板和 Safari 的 Web Inspector → Rendering → “Show Compositing Borders” 是唯一直观方式；单纯靠 transform: translateZ(0) 或 will-change 并不保证成功。
- 在 Chrome 中打开 DevTools → ⚙️ Settings → Preferences → Advanced → 勾选 “Enable paint flashing”，动画时若大面积绿色闪动，说明仍在重绘，没进合成层
- Safari 中启用 “Show Compositing Borders” 后，只有带橙色边框的元素才是独立图层；没有边框 = 主线程渲染 = 高概率卡顿
- 用
getComputedStyle(el).transform检查运行时值，如果返回none但本应有位移，说明动画被降级或被阻断（比如父元素overflow: hidden截断了合成层提升）
@keyframes fadeSlide {
0% {
opacity: 0;
transform: translateX(-10px);
}
100% {
opacity: 1;
transform: translateX(0);
}
}
.animated-element {
animation: fadeSlide 0.25s ease-out forwards;
/* 必须加这行，否则 Safari 可能不保持最终态 */
will-change: transform, opacity;
}
动画兼容性问题多数不是“写法错”，而是“浏览器把你的意图当成了降级信号”。重点不是让所有浏览器表现完全一致，而是让它们都走同一条高性能路径——这条路径只认 transform 和 opacity，别的都算额外负担。
立即学习“前端免费学习笔记（深入）”；
