直接减少透明图层数量是最有效方式；opacity
因为 opacity 属性会强制浏览器将整个元素及其子树提升为独立合成层（Compositing Layer），这是渲染流水线中“合成阶段”的硬性规则，不是可选优化，而是必须行为。
opacity 触发图层提升是合成阶段的强制策略
浏览器在 Composite 阶段需要把多个图层混合输出最终画面。opacity 的语义是“整棵 DOM 子树统一应用 Alpha 混合”，这就要求它不能和父层或兄弟层共享同一张纹理——否则无法单独做透明度混合。所以一旦设了 opacity 值不等于 1，浏览器必须立即将该元素及其全部后代打包成一个新图层，并分配 GPU 纹理内存（通常约 4MB/层）。
- 哪怕只写
opacity: 0.99，也会触发升层；opacity: 1是唯一不触发的例外 - 这个过程发生在 Paint 之后、Composite 之前，完全绕过 Layout 和 Paint 重计算，但代价是显存开销
- 子元素自己再设
opacity不会新增图层（已属于父级图层内），但会叠加透明度乘法计算
和 rgba() 完全不同：后者不升层，只改颜色值
rgba() 是颜色模型的一部分，仅影响某个属性（如 background-color）的像素输出值，不改变元素的合成边界。浏览器仍把它当作普通绘制内容，走 Paint 流程，不会额外创建合成层。
- 写
background-color: rgba(0,0,0,0.5)→ 仅背景半透，不升层，不影响子元素定位或层级 - 写
opacity: 0.5→ 整个元素+文字+子元素都变半透，且必然升层，可能引发内存暴涨 - 如果同时用两者：
opacity: 0.5+background-color: rgba(255,0,0,0.5)，最终 alpha = 0.5 × 0.5 = 0.25
容易被忽略的连锁反应
看似只是调个透明度，实际可能悄悄拖垮性能：
立即学习“前端免费学习笔记（深入）”；
- hover 时临时加
opacity: 0.8？→ hover 进入瞬间申请一块 4MB 显存，离开时未必立即释放 - 列表项批量加
opacity动画？→ 每一项都独立升层，100 条 = 至少 400MB 显存瞬占 - 配合
will-change: opacity？→ 提前预分配图层，问题更早暴露，但没解决根本 - 用 Chrome DevTools 的
Layers面板或开启chrome://flags/#show-layer-borders可直接看到哪些元素被升层
真正要控制透明效果又不想升层，优先用 rgba() 或 hsla() 替代 opacity；若必须用 opacity（比如做淡入动画），务必确认该元素是孤立的、无大量子节点的轻量容器，否则 GPU 内存压力会来得比预期快得多。
