分层合成是浏览器通过CSS触发、GPU承载的底层渲染机制，旨在将静态内容冻结为独立纹理仅参与合成；而Canvas分层仅为视觉分离，未触发合成层时仍共用主线程绘制上下文。

什么是分层合成，它和 Canvas 分层有啥区别

分层合成（Composite Layers）是浏览器渲染引擎的底层机制，不是你手动画几个 就算数的。它由 CSS 触发、GPU 承载，核心目标是让静态内容“冻结”在 GPU 纹理中，只参与合成（compositing），不参与每帧的 Layout + Paint。Canvas 分层只是视觉上的分离，若没触发合成层，所有 Canvas 仍跑在主线程、共享同一绘制上下文，改一个像素照样重绘整层。

关键判断标准：chrome://render-internals 里能看到 “Composited layers” 数量；DevTools → Layers 面板能直观看到哪些元素被提升为独立图层。

怎么可靠地触发静态层提升

别迷信 transform: translateZ(0) —— 它在某些 Android WebView 或旧版 Safari 上已失效，且可能引发意外重排或内存泄漏。优先用语义明确、浏览器支持稳定的方案：

• will-change: transform：仅对真正会动画的元素设置，避免滥用（设在父容器上不如设在粒子容器自身）
• contain: layout paint style：对静态地图瓦片容器加这个，浏览器会明确知道其内部变化不影响外部布局，极大降低合成判定成本
• opacity: 0.99：比 1 小一点即可触发，但仅限不需要精确透明度的场景（比如 UI 背景遮罩）
• 确保该元素有明确的 stacking context（例如 position: relative + z-index: 1），否则 will-change 可能被忽略

错误示范：div { will-change: transform; animation: slide 2s infinite; } —— 动画一停，图层没销毁，显存持续占用。

静态层内容更新时，如何避免“假静态”问题

很多项目把地形、UI 背景标为“静态”，结果玩家换皮肤、切语言、开/关 HUD 就卡一下——因为 DOM 更新强制触发了整层重绘。这不是分层没用，而是没管住更新源：

• 静态层内禁止直接操作 innerHTML 或频繁修改 textContent；文字类内容用 CSS ::before/::after + content 属性控制，或走 CSS 变量（var(--ui-title)）
• 地图瓦片用 标签 + decoding="async" 加载，配合 image-rendering: pixelated 防缩放模糊；别用 drawImage() 在 Canvas 里反复画
• 如果必须 JS 控制静态层内容（如赛季图标），用 requestIdleCallback() 延迟到空闲帧再批量更新，而非响应式立即执行

注意：transform 动画本身不会导致重绘，但若静态层内有 filter: blur(2px)，每次动画都会触发高斯模糊重计算，性能开销接近全量重绘。

动态层怎么避免拖垮合成性能

动态层不是“随便动就行”。浏览器对每帧合成的图层数量、纹理大小、混合模式都有隐性限制。移动端尤其敏感：

• 单个动态层分辨率别超视口 2 倍（比如 1080p 屏幕，动态 Canvas 最好 ≤ 2160×1200），否则纹理上传 GPU 成瓶颈
• 禁用 ctx.imageSmoothingEnabled = true（默认值），像素风游戏务必设为 false，否则每个 drawImage() 都触发双线性插值
• 粒子系统不用 globalAlpha 做淡入淡出，改用 rgba(r,g,b,a) 直接设 fillStyle；后者走 GPU 混合，前者强制 CPU 预乘 alpha
• 动态层 Canvas 启用 desynchronized: true（需搭配 OffscreenCanvas 使用），跳过主线程同步等待

最容易被忽略的一点：合成层之间重叠区域越多，Overdraw 越高。哪怕全是不透明层，GPU 也要按 stacking order 逐层采样——UI 层盖在角色层上，就比角色层盖在 UI 层上更耗资源。