真正触发硬件加速的CSS属性是transform、opacity和filter，它们使元素提升至GPU独立合成层，避开CPU的layout和paint；而left、top等布局属性会强制重排重绘，无法加速。
直接用 transform、opacity、filter 这三类属性，就能让浏览器自动把元素提升到独立合成层，交由 GPU 渲染，避开 CPU 主线程的 layout 和 paint 流程。硬件加速不是靠加特效“开开关”，而是靠选对属性、控好图层数量、避免误触发。
哪些 CSS 属性真正触发硬件加速
只有极少数属性被现代浏览器（Chrome 98+、Safari 16.4+、Edge 114+）实际支持并创建合成层：
- transform（含 translateX/Y/Z、scale、rotate 等）
- opacity
- filter（如 blur()、brightness()、contrast()）
- backdrop-filter（仅限支持该特性的上下文，如模态框背景）
像 left/top/width/height/background-color 这类属性，改了就会强制触发布局（reflow）和重绘（repaint），完全走 CPU 路径，再加 will-change 也无效，甚至更卡。
别乱用 will-change
静态写 .el { will-change: transform; } 已基本失效 —— 浏览器默认会对 transform/opacity 动画自动建层。全局声明等于长期占用 GPU 图层资源，一屏几十个列表项全带这个，内存飙升、滚动掉帧是常态。
立即学习“前端免费学习笔记（深入）”；
安全做法是动态设置 + 双 requestAnimationFrame 清除：
- 动画开始前：element.style.willChange = 'transform';
- 动画结束后：requestAnimationFrame(() => { requestAnimationFrame(() => { element.style.willChange = 'auto'; }); });
第一帧进渲染队列，第二帧确保图层已稳定合成，避免闪屏或撕裂。
控制图层规模，避免嵌套浪费
GPU 图层不是越多越好。每个图层都要内存、纹理上传、合成调度，过度分层反而拖慢性能。
- 别在父容器和子元素同时设 transform 或 will-change —— 图层嵌套会放大开销
- 长列表中慎用 content-visibility: auto + filter 动画组合，不可见区域虽不渲染，但一旦进入视口就可能批量建层
- 移动端尤其敏感：iOS Safari 图层管理保守，常驻图层易引发白屏或卡死
验证是否真起了作用
别凭感觉加加速，用 Chrome DevTools 实锤：
- 打开 Layers 面板，看目标元素是否生成了独立图层（Layer）
- 录制 Performance，重点观察 Composite 阶段耗时：若主线程空闲但 Composite 延迟高、帧率低于 60fps，才是硬件加速能解决的问题
- 若主线程满载、Layout/Paint 占比高，说明瓶颈在 JS 或样式计算，加硬件加速没用，得先优化逻辑或减少 DOM 操作
