transform: translateZ(0) 通过触发图层提升将动画交由 GPU 处理，避免 CPU 重排重绘；但现代浏览器已弱化其效果，且滥用会导致内存暴涨、掉帧，应配合 will-change: transform（更标准、可控）谨慎使用，并用 DevTools 验证图层数与 FPS。
为什么 transform: translateZ(0) 能触发硬件加速
它本质是告诉浏览器：“这个元素要频繁变换位置，别用 CPU 做合成，交给 GPU”。现代浏览器会把加了 translateZ(0) 的元素提升为独立图层（layer），后续的 transform 和 opacity 变化就在 GPU 上做光栅化，不触发布局（layout）和重绘（paint）。
但注意：不是所有设备都买账。iOS Safari 15.4+、Chrome 100+ 已大幅弱化该 hack 的效果；旧 Android WebView 或低端平板可能反而因图层过多导致内存暴涨、掉帧。
- 只对有动画/滚动交互的元素加，别全局塞
translateZ(0) - 避免在
:hover或@media里动态加，图层升降本身有开销 - 用 Chrome DevTools 的 “Layers” 面板确认是否真建了新图层（按
Cmd+Shift+P→ 输入Layers）
will-change: transform 比 translateZ(0) 更靠谱吗
是的，will-change 是 W3C 标准声明，语义明确：提前告知浏览器“接下来我要动这个属性”。浏览器可据此预分配资源、延迟图层创建时机，比盲目提 layer 更可控。
但它不是万能开关：设了 will-change: transform 却一直不动，图层长期驻留，显存白占；设成 will-change: scroll-position 却没监听滚动，纯属误导。
立即学习“前端免费学习笔记（深入）”；
- 仅在动画开始前 1–2 帧设置，动画结束立即设回
auto（用 JS 控制） - 不要写在 CSS 文件顶层，比如
.card { will-change: transform; }—— 这等于让所有卡片永远占着 GPU 内存 - 支持度没问题：Chrome 36+、Firefox 36+、Safari 9.1+，但 IE 完全不支持
哪些场景下硬加加速反而更卡
图层不是越多越好。每个图层要单独上传纹理、维护状态、参与合成，GPU 显存和带宽有限。当页面图层数超阈值（如 iOS 上常为 16–32 层），浏览器会降级回 CPU 合成，甚至强制丢帧。
典型翻车现场：
- 给整个
.list-item加will-change，列表一屏 50 条 → 瞬间 50 个图层 - 在
position: fixed导航栏上加translateZ(0)，再叠加backdrop-filter→ 多重离屏渲染，iOS 直接糊屏 - 用
transform: translateZ(0)强提一个含大量文本的div→ 文本重排版仍走 CPU，GPU 白等
验证有没有真正加速：看三个指标
别信“看起来流畅”，要看真实数据。打开 Chrome DevTools → Cmd+Shift+P → 输入 Rendering → 勾选 “FPS Meter”、“Layer Borders”、“Paint Flashing”：
- 绿色 FPS 数字稳定在 58–60：大概率 GPU 在干活
- 红色边框（Layer Borders）只出现在动的元素上，且数量合理（≤10）：图层控制得当
- 动画期间没有大面积黄色闪烁（Paint Flashing）：没频繁重绘
- 若看到紫色块（Compositing Layers），说明浏览器正在强制升层——这时候查是不是写了
will-change: opacity却没配transform，触发了意外合成
复杂点在于：同一段 CSS，在 Mac M1 和 Android 旧机上的图层策略可能完全不同。别依赖单一设备测试结果。
