硬件加速不是开关，而是图层管理策略；盲目加translateZ(0)或will-change会加剧低端设备卡顿，真正有效的是精准升层、仅用transform/opacity驱动动画并及时清理。
硬件加速不是开关，而是图层管理策略；盲目加 transform: translateZ(0) 或 will-change: transform 反而会让低端 Android 和 iOS Safari 更卡——真正起效的是精准升层 + 仅用 transform 和 opacity 驱动动画，且必须及时清理。
为什么加了 translateZ(0) 还是掉帧
因为 translateZ(0) 只是触发图层提升，但原生滚动（scrollTop）、vw 单位计算、filter 或 border-radius 等 CSS 属性会强制浏览器回退到 CPU 渲染，让 GPU 图层空转。尤其在 Android WebView 或 iOS Safari 14 以下，内存压力直接导致掉帧甚至白屏。
常见错误现象包括：
- 手指一松惯性消失，滚动“顿挫”
- DevTools 的 Layer Borders 显示大片绿色，但 FPS 掉到 30 以下
- 快速滑动时内容“跳变”或延迟响应
根本原因：硬件加速只对 transform 和 opacity 的变化生效，对布局（Layout）、重绘（Paint）无优化作用。
立即学习“前端免费学习笔记（深入）”；
哪些属性动起来才真不掉帧
只有两个属性能稳住 60fps： transform 和 opacity。其他所有属性——top、left、width、height、margin、background-color、box-shadow、filter ——只要参与动画，整段都会降级回 CPU 渲染。
安全写法示例：
@keyframes slide {
from { transform: translateX(-100%); opacity: 0; }
to { transform: translateX(0); opacity: 1; }
}
必须避开的组合：
-
transition: all 0.3s→ 混入任意非合成属性即失效 -
transform: translateX(50vw)→vw触发每帧 Layout，will-change完全无效 -
filter: blur(2px)→ 低端安卓机 CPU 做高斯模糊，一开就掉帧
will-change 怎么用才不翻车
will-change 是提示，不是保险丝；它不保证建层，也不控制回收时机。静态写死 .item { will-change: transform; } 等于给每个列表项预分配 GPU 内存，在一屏 20 个元素的场景下极易 OOM 卡死。
正确做法是动态控制：
- 动画开始前一帧（如
touchstart或requestAnimationFrame第一帧）执行el.style.willChange = 'transform' - 动画结束时监听
transitionend或animationend，立刻执行el.style.removeProperty('will-change') - iOS Safari 对 ≤16ms 动画可能不触发事件，必须加兜底：
setTimeout(() => el.style.willChange = 'auto', duration + 100) - 绝对不要在
@media查询里写will-change，视口缩放会持续创建新图层
移动端滚动卡顿的真正解法不是加加速，而是明确手势意图
原生滚动卡顿主因不是“没加速”，而是浏览器默认等 300ms 判定是否双击，导致 touchmove 延迟触发。必须用 touch-action 显式声明意图，再只对当前位移的子元素临时升层。
关键组合：
- 滚动容器设
touch-action: pan-y（纵向）或pan-x（横向），禁止none除非你完全接管手势 - 滚动开始时（
touchstart或首个touchmove），给实际位移的子元素（如.list-content）加style.willChange = 'transform' - 滚动结束 100ms 后（监听
touchend+setTimeout），立刻清除will-change - 若子元素含可点击区域（如卡片），需单独加
touch-action: manipulation，否则点击失效
最容易被忽略的一点：所有优化都建立在「避免同步 Layout」之上。哪怕 CSS 全写对了，只要 JS 在动画中调了一次 getBoundingClientRect() 或 offsetHeight，就会打断渲染流水线，前面所有加速都归零。
