会意外触发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 解决。
