硬件加速通过transform: translateZ(0)、opacity或will-change: transform等CSS声明，提前触发浏览器创建独立合成层，将元素及其子树升至GPU图层，实现动画前的预分配与隔离渲染。
硬件加速如何把元素“提前升层”
浏览器不会等你动画开始才建合成层，而是根据 CSS 声明提前判断是否要为某个元素创建独立 GPU 图层。一旦用了 transform: translateZ(0)、opacity 或 will-change: transform，它就可能把该元素及其全部子树打包进一个新图层——这个动作叫“提升（promotion）”。结果就是：原本和父容器在同一渲染上下文里混合的 rgba() 背景，现在先在子图层内部混合一次，再整体叠到父背景上。视觉上更暗、过渡更生硬，不是颜色错了，是多了一次 alpha 混合。
rgba() 和 opacity 混用会触发双重衰减
如果你给一个已启用硬件加速的容器设了 opacity: 0.8，同时子元素又写了 color: rgba(255, 0, 0, 0.8)，那文字实际 alpha 是 0.8 × 0.8 = 0.64。浏览器把整个图层当做一个纹理统一乘以 opacity，子元素的 rgba 不再独立生效。这不是 bug，是合成模型的必然行为。
- 避免方案：只用一种透明控制方式——要么全用
opacity控制整块区域，要么全用rgba()控制局部色值 - 特别注意：CSS 动画中混写
transition: opacity, background-color会直接让整段退化回 CPU 渲染，失去升层意义
translateZ(0) 不修复颜色，只增加图层
transform: translateZ(0) 是最常被误用的“硬件加速开关”，但它本身不改变任何颜色计算逻辑，也不提升 rgba 精度。它只是强制建层，代价是内存占用上升——每个图层在 iOS 上约消耗 0.5MB 显存，Android 中低端机更容易因图层过多而卡顿或闪屏。
- 真正需要它的场景极少：仅限老 Android 4.4 WebView 或 Safari 14 以下版本中无法自动识别动画意图时
- 现代浏览器（Chrome 80+ / Safari 14+）已能基于用户交互（如
touchstart）动态建层，静态加translateZ(0)反而干扰优化 - 高密度列表项（如商品卡片流）滥用此写法，极易触发 GPU 内存溢出
Safari 渐变抖动不是抗锯齿问题
Safari 15.4 之前对 linear-gradient 中高频变化的 rgba() 色标存在浮点归一化截断，比如把 0.7 存成 0.69999999，再转回整数通道时偏移 1 个单位。这不是模糊，是颜色值在 GPU 合成路径里被悄悄改写了。
立即学习“前端免费学习笔记（深入）”；
- 临时缓解：把 alpha 写成三位小数，例如
rgba(0,0,0,0.700) - 稳定解法：放弃渐变 alpha，改用两层不透明色块 +
background-blend-mode: multiply -
backface-visibility: hidden对此无效，纯属社区误传
