分层渲染不是加transform: translateZ(0)就完事，需满足will-change/opacity/filter/transform动态变化等合成条件；Canvas应按更新频率分层，3D中fixed会破坏合成，层数宜控制在4–6层。
分层渲染不是加个 transform: translateZ(0) 就完事
很多人以为只要给元素加个硬件加速 CSS 属性，就算做了分层渲染。实际完全不是——浏览器只会在满足特定条件时真正创建独立合成层（compositing layer），否则只是“假装加速”。关键判断依据是：该元素是否被标记为 will-change: transform 且后续确实发生了 transform 变化；或者是否已有非 none 的 opacity、filter、transform 值且这些值在 JS 中被持续修改。静态加了但没动，不会触发图层提升；动了但没满足合成条件（比如只改 top），照样走 layout 流水线。
2D 场景下哪些元素该拆成独立 Canvas 层
Canvas 分层不是按“功能模块”切，而是按“更新频率”切。例如歌词组件中：backgroundBlur 几乎不变，应画在底层层；currentLine 每秒变 1–2 次，可单独一层；progressIndicator 每帧都动，必须再拆一层。不这么做，哪怕只改一个像素的进度条，也会触发整块 Canvas 的重绘（ctx.clearRect() + 全量重画）。
- 高频更新区（如播放进度、实时音效波形）→ 单独
canvas元素，width/height固定，仅清空+重绘局部 - 中频更新区（如当前行高亮、时间戳）→ 合并进同一层，用
requestAnimationFrame统一批量更新 - 静态/低频区（如背景模糊、歌词字体样式）→ 首次绘制后缓存为
ImageBitmap或离屏canvas，不再调用drawImage
3D 应用里误用 position: fixed 会直接废掉分层效果
WebGL 或 Three.js 场景中，常有人把 UI 控件（如播放按钮、设置面板）用 position: fixed 叠在 canvas 上。这会导致整个 canvas 被强制降级为“非合成根节点”，即使你对 canvas 设置了 will-change: transform，浏览器也无法将其提升为独立图层——因为 fixed 元素会参与顶层 stacking context，破坏图层隔离边界。结果就是：UI 动画一动，整个 3D 渲染层跟着重绘。
正确做法是：UI 容器 使用 transform: translateZ(0) + contain: layout paint，同时确保它和 canvas 处于同一 stacking context，且不触发 overflow: hidden 或 clip-path 等剪裁行为（这些也会打断合成）。
合成层太多反而拖慢性能，临界点通常在 4–6 层
每个合成层都要分配 GPU 内存、维护纹理、参与合成器排序。Chrome DevTools 的 Layers 面板能直观看到当前页有多少层。超过 6 层后，合成器开销（尤其是移动端）会明显上升，表现为 FPS 波动、内存占用激增。这不是理论值，是实测数据：某金融 K 线应用从 8 层压到 5 层后，低端安卓机平均帧率从 41fps 提升至 57fps，GPU 内存下降 32%。
真正要盯住的不是“能不能分层”，而是“哪几层值得保、哪几层可以合”。比如歌词组件里，lineHighlight 和 lineShadow 完全可以合并绘制，没必要各自占一层；而 audioWaveform 必须独立——因为它每帧都在变，且变化区域不规则，无法通过差量更新优化。
