iPhone上CSS动画卡顿主因是WebKit渲染引擎未启用GPU加速，须同时写transform和-webkit-transform、搭配opacity:0.99或will-change（动态增删）、禁用translateZ(0)及left/right位移，避免steps()并真机测试iOS 14–16。
iPhone上CSS动画卡顿，不是代码写错了，而是浏览器没按你想的走GPU渲染路线——尤其在Chrome for iOS、微信WebView、Safari旧版本里，transform不加-webkit-前缀，或用了非合成属性，就大概率掉帧。
为什么transform不加-webkit-前缀会卡
iOS所有浏览器（包括Chrome for iOS）底层都用WebKit渲染引擎，但它们对CSS标准的支持节奏不同。2023年之后的Safari已全面支持无前缀transform，但微信WebView、某些iOS 14–16的Chrome、以及部分PWA环境仍依赖-webkit-transform触发硬件加速路径。漏掉前缀时，浏览器可能退回到CPU绘制，尤其在连续translateX跑马灯、缩放旋转等场景下，帧率直接掉到20–30fps。
实操建议：
- 所有涉及动画的
transform声明，必须同时写两行：transform: translateX(100px);和-webkit-transform: translateX(100px); - 不要只写
-webkit-版而漏掉标准版——现代Safari和安卓Chrome会忽略前缀版，导致动画彻底失效 - 如果用PostCSS自动补全，确认插件配置包含
autoprefixer且browserslist含iOS >= 12，否则可能跳过iOS旧版本前缀
opacity和transform必须配对使用才真正启用GPU加速
单写transform不一定触发合成层（compositing layer）。iOS WebKit要求：只有transform + opacity组合，或加上will-change: transform，才会把元素提升为独立图层交由GPU处理。否则，哪怕写了translateZ(0)，在部分iOS WebView中仍可能被降级。
立即学习“前端免费学习笔记（深入）”；
常见错误现象：动画开始几帧流畅，持续1秒后突然卡顿——这是图层被回收又重建的表现。
实操建议：
- 给动画元素显式加
opacity: 0.99（不能是1，否则WebKit可能跳过合成） - 或加
will-change: transform，但注意：仅在动画开始前1帧设置，动画结束后立即移除，避免内存泄漏 - 禁用
translateZ(0)这种“伪提升”写法——它在iOS上效果不稳定，且容易引发额外重绘
跑马灯类动画在iOS首次不执行？检查width是否动态撑开
接口异步加载文字后拼成跑马灯内容，但@keyframes marquee在iOS上不动，息屏再亮才跑——这不是缓存问题，是元素width为0导致位移计算失效。WebKit在首次渲染时若width不可知，会跳过动画初始化。
实操建议：
- 给跑马灯容器设
min-width: 200px兜底，但更稳妥的是用JS拿到真实文本宽度后，动态设置style.width - 避免用
position: absolute+left/right做位移——iOS对这些属性的动画优化极差，坚持用transform: translateX() - 动画时长别设太长（如
100s），iOS对超长周期动画调度不敏感；改用20s+iteration-count: infinite更稳
steps()在iOS上基本不可靠，换掉它
animation-timing-function: steps(8, end)这类逐帧动画，在iOS 15之前几乎必然卡顿或跳帧。WebKit对steps()的实现未完全收敛，尤其当配合transform缩放或旋转时，帧间隔抖动明显。
实操建议：
- 用
cubic-bezier(0.33, 0, 0.67, 1)模拟匀速感，比steps()更兼容 - 真需要逐帧效果（如像素风），改用JS控制
requestAnimationFrame+ 切换background-position，避开CSS timing function缺陷 - 测试时务必在真机iOS 14–16上验证，Simulator无法复现此问题
最常被忽略的一点：iOS上动画性能瓶颈往往不在“怎么写”，而在“什么时候写”。will-change提前声明、transform双前缀、opacity微调值——这些都不是可有可无的修饰，而是绕过WebKit渲染管线缺陷的必要条件。漏掉任意一项，都可能让同一段代码在安卓丝滑、在iPhone卡成PPT。
