层合成提升本身不直接申请独立缓存渲染上下文，而是由图形系统自动触发的优化行为；当元素满足will-change、3d变换、opacity
层合成提升（Layer Promotion）本身不是向 GPU 申请独立缓存渲染上下文的直接手段，而是一种由图形系统（如 WebKit、Skia、Core Animation 或 Android RenderThread）自动触发的优化行为——它会在检测到某 DOM 元素/视图满足特定条件时，将其提升为独立图层（offscreen layer），并隐式创建对应的 OpenGL/Vulkan 上下文与帧缓冲对象（FBO）。真正“申请独立缓存渲染上下文”的动作，发生在底层图形栈对这个图层的初始化阶段。
哪些条件会触发层合成提升
只有满足以下至少一项，系统才可能为其分配独立上下文：
- 设置了 will-change: transform 或 will-change: opacity（显式提示浏览器该元素将频繁变化）
- 应用了 transform: translateZ(0)、translate3d(0,0,0) 等强制启用硬件加速的 CSS 变换
- 元素带有 opacity 且非根图层（需隔离混合）
- 元素使用了 filter（如 blur、contrast）、mask 或 clip-path 等无法在主合成器中高效处理的效果
- 元素是 video、canvas 或 iframe 等原生可绘制内容载体
如何确认上下文已成功创建并被复用
不能仅靠样式判断，需结合运行时观测：
- 在 Chrome DevTools → Rendering → ✅ “Paint flashing” 和 “Layer borders”，看到该元素被绿色边框包围，即表示已提升为独立图层
- 打开 DevTools → More Tools → Layers 面板，可查看每个图层的尺寸、内存占用、是否启用 FBO、绑定的纹理 ID 等信息
- 若使用 WebGL 或自定义 OpenGL 渲染，可通过 glGetIntegerv(GL_CONTEXT_PROFILE_MASK, ...) 或调试器捕获上下文句柄（如 EGLContext / GLXContext），验证其与主线程默认上下文不同
避免无效提升与资源浪费
盲目提升会导致过多离屏渲染，反而增加 GPU 带宽和内存压力：
- 不要对大量静态元素批量加 translateZ(0)；优先用 will-change 并在动画结束后移除
- 避免嵌套多层提升（例如父容器 + 子元素都设 will-change），系统可能合并或降级处理
- 移动端尤其注意：iOS WebKit 对图层数量有限制（通常 ≤ 16），超出后会回退到 CPU 合成
- 检查是否真有性能收益：用 Performance 面板对比“提升前 vs 提升后”的 FPS、GPU Raster 时间、RenderLayerCount 指标
进阶：主动控制上下文生命周期（适用于原生开发）
在 OpenGL ES / Vulkan 应用中，若需更精细管理：
- 调用 eglCreateContext(..., share_context) 显式创建共享上下文，用于离屏渲染线程
- 为每个需要独立缓存的图层分配专属 FBO + texture，而非复用默认帧缓冲
- 动画开始前预分配上下文与纹理资源（避免首帧卡顿），动画结束时调用 eglDestroyContext 释放
- 参考迪捷软件专利中“提取进程ID、线程ID与上下文句柄生成唯一标识”的思路，在多线程渲染场景中确保上下文隔离
