17370845950

会意外触发GPU加速的CSS属性包括translateZ(0)、will-change: transform、filter: blur(1px)等，它们强制创建独立图层；应慎用will-change、避免全局filter、优先用box-shadow替代blur，并用contain控制图层范围。

哪些CSS属性会意外触发GPU加速

不是所有 transform 或 opacity 都安全。比如 transform: translateZ(0)、will-change: transform、甚至 filter: blur(1px) 都会强制创建独立图层，让浏览器把元素丢给GPU合成——但若页面有几十个这样的元素，GPU负载立刻飙升。

• will-change 应只在真正需要动画的元素上动态添加/移除，避免全局写死
• filter（尤其 blur、drop-shadow）是GPU大户，静态内容尽量用 box-shadow 替代
• transform: scale(1.001) 比 scale(1) 更容易触发图层提升，看似无害却埋雷

Chrome DevTools里怎么定位GPU过载源头

打开 chrome://gpu 看整体状态只是第一步。更关键的是在开发者工具中启用「Rendering」面板，勾选：Paint flashing（看重绘）、Layer borders（看图层爆炸）、FPS meter（看帧率跌穿 30fps 的节点）。

• 出现大量半透明边框（图层边界），说明 layer 数量失控；优先检查 position: fixed、opacity 、transform 组合使用的地方
• paint flashing 频繁闪红？说明 CSS 动画正在触发 Layout → Paint → Composite 全流程，而不是仅 Composite —— 这时应改用 transform + opacity，并确保不读取 offsetTop、getBoundingClientRect() 等触发同步布局的 API

如何用CSS containment控制图层范围

contain: layout paint style 能告诉浏览器：“这个容器内部的变化不会影响外部”，从而阻止不必要的图层提升和重绘扩散。它比盲目加 transform: translateZ(0) 更可控。

article {
  contain: layout paint;
  /* 不再因内部子元素 position: absolute 或 z-index 变化而提升整块 article 到新图层 */
}

• contain: strict 最强，但可能破坏 position: fixed 子元素的定位上下文，慎用
• 对列表项（
• ）、卡片（）、弹窗内容区这类独立区块，加 contain: layout paint 通常零副作用且显著降 GPU 压力
• 不要对 或根容器加 contain，它会切断继承链和事件冒泡逻辑

requestAnimationFrame里别干这三件事

很多 H5 动画库在 requestAnimationFrame 回调里直接操作 DOM 样式，结果每帧都触发 Layout → Paint → Composite，GPU 合成线程被反复打断。

• 别在 rAF 里读取 clientWidth、scrollLeft 等布局信息 —— 它会强制同步回流（forced synchronous layout）
• 别在 rAF 里修改多个样式属性（如同时改 left 和 top），改用单条 transform: translate(x, y)
• 别在 rAF 中调用 getComputedStyle() 查颜色或透明度 —— 改为缓存初始值或用 CSS 自定义属性 + CSS.supports() 预判

GPU 占用高往往不是“用了硬件加速”，而是“加速了不该加速的东西”。图层数量、合成频率、是否触发同步布局，这三个点卡住了就很难靠加 flag 解决。