iOS Safari中transition卡顿主因是非合成属性触发CPU重排重绘；仅transform和opacity可GPU加速；需谨慎用will-change、translateZ(0)/translate3d(0,0,0)，并避免布局抖动与不良timing function。
为什么 transition 在 iOS Safari 上卡顿
移动端（尤其是 iOS Safari）对非合成层属性的过渡会触发频繁重排重绘，transform 和 opacity 是仅有的两个能走 GPU 合成的 CSS 属性；一旦你写的是 transition: left 0.3s 或 transition: background-color 0.3s，浏览器只能靠 CPU 逐帧计算布局和绘制，帧率立刻掉到 20–30fps。
will-change 不是万能药，但该用还得用
它只是给浏览器一个“即将变化”的提示，不等于强制开启硬件加速。滥用反而增加内存开销、引发闪烁或白屏（尤其在低端安卓机上）。只对明确知道会频繁动画的元素谨慎启用：
- 只在动画开始前 1–2 帧设置，动画结束立即移除（避免长期占用图层）
- 优先写
will-change: transform，不要写will-change: left - 避免在父容器上设
will-change，影响子元素图层合并
element.addEventListener('mouseenter', () => {
element.style.willChange = 'transform';
});
element.addEventListener('animationend', () => {
element.style.willChange = 'auto';
});用 transform: translateZ(0) 还是 translate3d(0,0,0)？
两者都可触发 GPU 合成，但行为有差异：
-
translateZ(0)：语义清晰，只声明 Z 轴偏移为 0，兼容性好（iOS 6+） -
translate3d(0,0,0)：某些老版 Android WebView 对translateZ支持不稳定，用这个更保险 - 别写成
transform: translate3d(0,0,0) translateX(10px)—— 多余的 3D 变换会干扰浏览器图层判断
.slide-in {
transform: translateZ(0); /* 触发合成层 */
transition: transform 0.3s cubic-bezier(0.25, 0.46, 0.45, 0.94);
}
.slide-in.active {
transform: translateZ(0) translateX(100%);
}真正关键：避免触发布局抖动（layout thrashing）
即使加了硬件加速，如果 JS 频繁读写 offsetTop、getBoundingClientRect() 或修改 class 后立刻查 clientWidth，就会强制同步回流，把 GPU 加速的效果全抵消。
立即学习“前端免费学习笔记（深入）”；
- 动画中只读取一次尺寸，缓存结果
- 用
requestAnimationFrame批量读写，避免跨帧混用 - 用
IntersectionObserver替代 scroll + getBoundingClientRect 判断进入视口
最常被忽略的一点：iOS Safari 对 transition 的 timing function 非常敏感。用 cubic-bezier(0.25, 0.46, 0.45, 0.94) 比 ease-out 更稳，后者在部分 iOS 版本里会被降级为线性插值。
