旧版浏览器硬件加速支持不一致，需手动触发GPU合成：优先用translate3d(0,0,0)，慎用will-change和backface-visibility，transition须显式声明，避免layout thrashing，必要时用requestAnimationFrame实现JS动画替代。
旧版浏览器（如 IE11、Android 4.4 WebView、Safari 9）对 transition 的硬件加速支持不一致，很多卡顿不是因为代码写错，而是浏览器根本没走 GPU 合成层——你得手动“哄”它进加速通道。
哪些属性在旧浏览器里真能硬件加速
别信“transform 和 opacity 都行”这种笼统说法。在 IE11 和 Android 4.4 中：
-
transform: translate3d(0, 0, 0)比translateX()更可靠，后者可能被降级为软件渲染 -
opacity支持尚可，但若父元素有filter或overflow: hidden，整层会被拖回 CPU 渲染 -
will-change: transform在 IE11 完全无效，在 Android 4.4 可能引发闪烁，别用 -
backface-visibility: hidden在 IE11 中能强制创建独立图层，比translateZ(0)更稳
过渡声明必须写死，不能靠继承或覆盖
旧浏览器解析 transition 简写时容错率极低，常见失效场景：
- 父元素设了
transition: all .3s，子元素想只动transform→ 整个过渡被覆盖丢弃 - 媒体查询里重写了
transition，但没显式写出所有要过渡的属性 → 旧引擎直接清空前值 - JS 动态加 class 后立刻改
style.transform，但没等上一帧结束 → 过渡链断裂，退化为跳变
正确做法：每个需要过渡的元素，单独写完整声明，例如：transition: transform 0.3s cubic-bezier(.25,.46,.45,.94), opacity 0.3s ease;
立即学习“前端免费学习笔记（深入）”；
避免触发 layout thrashing 的隐式读取
旧浏览器对同步布局计算更敏感，一次 getBoundingClientRect() 就可能让整段动画卡住首帧：
- 不要在
transitionstart回调里读取offsetWidth或computedStyle - 避免在
touchstart中连续设置多个样式再读尺寸 —— 即使只读一次，也可能阻塞合成器初始化 - 用
requestAnimationFrame包裹读操作，且确保读写分离：“先批量写，下一帧再读”
尤其注意 iOS Safari 9–10：transitionend 可能延迟触发或丢失，加 setTimeout 兜底清理 will-change 或临时 class。
兜底方案：用 JS 动画替代 CSS transition
当兼容性要求压倒性能时，requestAnimationFrame + transform 手动插值反而更可控：
- 避开浏览器对
transition解析的差异（比如 IE11 不支持cubic-bezier自定义缓动） - 可精确控制帧节奏，避免旧引擎调度不准导致的掉帧
- 配合
transform: translate3d(x, y, 0)仍能触发 GPU 加速，只是由 JS 驱动
示例关键逻辑：
function animate(el, fromX, toX, duration) {
const start = performance.now();
const step = (now) => {
const t = Math.min((now - start) / duration, 1);
const x = fromX + (toX - fromX) * easeOutCubic(t); // 自带缓动
el.style.transform = `translate3d(${x}px, 0, 0)`;
if (t < 1) requestAnimationFrame(step);
};
requestAnimationFrame(step);
}
最易忽略的一点：旧浏览器里，哪怕你只动 transform，只要父容器用了 flex 或 grid 布局，就可能因内部重排逻辑不同而意外降级。验证方式不是看绿框，而是打开 IE11 的 F12 工具 → “UI Responsiveness” 面板，录一段动画，重点盯 “Paint” 和 “Layout” 时间是否突增。
