根本原因是box-shadow模糊计算依赖CPU软渲染，blur-radius每增2px，显存与重绘成本近似平方增长；filter:blur()叠加、大量卡片hover、rgba(0,0,0,0)初始值、单位混用等写法会雪上加霜。
box-shadow 过渡为什么拖慢页面
根本原因是浏览器对 box-shadow 的模糊计算必须走 CPU 软渲染，无法直接交给 GPU 合成。blur-radius 每增加 2px，显存占用和重绘成本就接近平方级增长——尤其在低端 Android WebView 或 iOS Safari 中，12px 模糊半径可能直接掉帧。
哪些写法会让性能雪上加霜
以下操作会显著放大渲染压力：
-
filter: blur()和box-shadow同时使用：后者会被前者覆盖，且两者叠加触发强制重绘 - 在大量卡片（>20 个）上同时 hover：没有节流或图层分离，GPU 帧率瞬间跌破 30fps
- 用
rgba(0,0,0,0)或transparent作初始阴影：部分旧内核无法插值，退化为逐帧重绘 - 混用单位，比如
box-shadow: 0 2px 4px ...→0 0.5rem 1rem ...：浏览器放弃线性插值，改用离散跳变
真正有效的性能优化点
不是“要不要用”，而是“怎么用才不卡”：
- 模糊半径控制在
8px以内，深色背景下甚至可用4px - 必须启用硬件加速：在默认状态加
will-change: box-shadow，但仅限 hover 触发前一刻添加，避免内存泄漏 - 用
transform: translateZ(0)替代纯box-shadow悬浮感：位移 + 微调阴影更轻量 - 移动端慎用多层阴影：单层
box-shadow比两层叠加快 40% 以上，iOS Safari 尤其敏感
容易被忽略的兼容陷阱
某些优化在开发机上看很顺，上线后在低端安卓机上直接卡死，原因常是：
立即学习“前端免费学习笔记（深入）”；
-
will-change在 Android 10 以下 WebView 中反而降低性能 - OLED 屏幕对低 alpha 值（如
rgba(0,0,0,0.06)）渲染异常，需实测调整 - 父容器设了
opacity或transform，会截断子元素box-shadow的层叠上下文，导致阴影“消失”而非“变淡”
