iOS HTML5动画卡顿主因是Safari渲染机制与WebKit硬件加速策略差异：需用will-change: transform提前触发GPU加速，避免重排、同步布局读取及overflow: hidden等降级行为，并优先采用requestAnimationFrame和优化贝塞尔曲线。
为什么 iOS 上 HTML5 动画卡顿
根本原因不是动画本身写得差，而是 Safari 的渲染机制和 WebKit 的硬件加速策略与桌面 Chrome 不同。iOS Safari 默认对 transform 和 opacity 做 GPU 加速，但一旦触发动态样式计算（比如改 left、top、width）、强制重排（reflow）或频繁读取 offsetTop 等布局属性，就会退回到 CPU 渲染，帧率立刻掉到 20–30fps。
必须用 transform + will-change 触发硬件加速
仅靠 transform: translateX(10px) 不够，iOS Safari 对触发 GPU 层的条件更苛刻：
-
will-change: transform要提前加在动画元素上（不是动画开始时才加），且不能滥用——加在太多元素上反而引发内存压力和图层爆炸 - 避免同时设置
transform和opacity在同一元素上做动画，iOS 15+ 之前容易导致图层合成失败；拆成两个嵌套元素更稳 - 慎用
transform: scale()动画，缩放会触发高倍数重绘，尤其配合border-radius或阴影时，直接卡顿
示例写法：
.anim-box {
will-change: transform;
}
.anim-box::before {
content: '';
position: absolute;
top: 0; left: 0; right: 0; bottom: 0;
background: #fff;
transform: translateZ(0); /* 强制创建独立合成层 */
}用 requestAnimationFrame 替代 setTimeout 或 CSS @keyframes
iOS Safari 对 CSS 动画的调度不如 JS 精准，尤其在页面切后台再切回、或低电量模式下，@keyframes 容易跳帧或暂停；而 setTimeout 时间不可控，无法对齐屏幕刷新节奏：
立即学习“前端免费学习笔记（深入）”；
- 所有逐帧控制逻辑（如滚动视差、路径动画）必须走
requestAnimationFrame - 动画中避免同步读取
getBoundingClientRect()或offsetHeight，改用IntersectionObserver或事件节流后的回调获取位置 - 若必须用 CSS 动画，优先选
animation-timing-function: cubic-bezier(0.33,1,0.68,1)（即ease-out变体），iOS 对这个贝塞尔曲线优化更好
避开 iOS WebKit 的几个隐藏坑
有些行为看似合理，但在 iOS 上就是拖慢动画：
-
body { overflow: hidden }会导致整个页面合成层失效，动画区域可能被降级为软件渲染 - 使用
input[type="range"]或textarea期间，键盘弹出会重置渲染上下文，正在播放的动画大概率中断——需监听focusin/blur暂停/恢复 - iOS 16+ 开始限制
canvas的 WebGL 上下文生命周期，如果动画依赖requestAnimationFrame+canvas.drawImage，务必检查canvas.getContext('2d')是否返回null（被系统回收） - 不要在
touchmove里直接修改样式，必须用{ passive: false }并event.preventDefault()，否则 iOS 会延迟 300ms 才响应，造成明显滞后
真正影响流畅度的，往往不是动画复杂度，而是这些 WebKit 特定行为是否被显式处理。没踩过坑的人，常以为是“iOS 性能差”，其实只是没对齐它的渲染预期。
