box-shadow动画触发大面积重绘，因其依赖CPU绘制阶段，无法跳过Paint直入Composite；blur半径增大导致像素采样量平方级增长，多层阴影叠加引发多次独立绘制，且父容器创建新层叠上下文会锁死阴影、引发合成层爆炸。
box-shadow 动画本身不直接消耗 GPU，真正卡住的是合成层管理失控导致的重绘爆炸和内存泄漏。
box-shadow 动画为什么触发大面积重绘（repaint）
浏览器对 box-shadow 的渲染依赖于绘制阶段（Paint），它不是“纯合成属性”，不能像 transform 或 opacity 那样跳过 Paint 直接走 Composite。每次阴影参数变化（比如 blur、spread 或颜色），浏览器必须重新生成整块阴影区域的位图——这个过程在 CPU 上完成，且无法复用上一帧的绘制结果。
- 模糊半径（
blur-radius）越大，像素采样量呈平方级增长，CPU 绘制耗时飙升 - 多个
box-shadow叠加（如0 2px 4px #000, 0 4px 8px rgba(0,0,0,0.1)）会触发多次独立绘制，而非一次合并 - 如果元素父容器有
overflow: hidden或clip-path，阴影会被裁切，但裁切逻辑仍需在 Paint 阶段实时计算，进一步拖慢
layer explosion（合成层爆炸）是怎么发生的
问题不在阴影本身，而在它所处的层叠上下文（stacking context）。一旦父容器意外创建新层叠上下文（例如设置了 opacity: 0.99、transform: translateZ(0)、filter: blur(0.5px)），子元素的 box-shadow 就被“锁死”在该层内，无法与兄弟元素共享图层。
- Chrome DevTools → Rendering → 勾选 “
Layer borders”，能看到阴影被包裹在异常宽大的绿色边框里——这就是层爆炸的视觉证据 - 每个带阴影的卡片都单独建层，10 个卡片 = 至少 10 个独立纹理，GPU 显存占用陡增，iOS Safari 下极易触发层回收或丢帧
- 移动端低电量模式下，Safari 会主动丢弃第 2 层以后的
box-shadow，DevTools 完全无法模拟该行为
为什么给阴影元素加 will-change: transform 反而更糟
这是最典型的误操作：will-change: transform 是告诉浏览器“这个元素即将做 transform 动画”，但它对 box-shadow 变化毫无优化作用；反而会强制提升图层，把本可复用的绘制内容隔离成独占纹理。
立即学习“前端免费学习笔记（深入）”；
- 正确做法是：给阴影元素的直接父容器设
will-change: transform或更轻量的contain: paint -
contain: paint显式声明渲染边界，比will-change更可控，且不会引发内存泄漏 - 绝对避免在
position: fixed容器里嵌套带多层阴影的卡片——fixed 元素自带强层叠上下文，阴影无法穿透到 body 背景层，常表现为阴影突然变淡或消失
真机测试时最容易忽略的三个点
性能问题往往只在真实设备上暴露，而 DevTools 里一切正常。
- iOS Safari 对
transform: translateZ(0)的图层管理极不稳定，优先用contain: paint - Android WebView 在低端机型上对多层
box-shadow的绘制延迟可达 80ms/帧，远超 16.7ms 的 60fps 红线 - 阴影动画若与
transform同时变化（例如 hover 时既放大又加阴影），浏览器可能放弃所有优化，退回到纯软件渲染
真正要盯住的不是“怎么让 shadow 动起来”，而是“谁在承载它、它被锁在哪个上下文里、有没有被强制重绘”。层叠上下文看不见摸不着，却是所有掉帧的隐形推手。
