box-shadow 性能问题根源在于触发离屏渲染与高斯模糊计算，blur-radius 超过4px显著掉帧，overflow: hidden 会裁剪阴影，transition box-shadow 不可硬件加速，应优先用 transform/opacity 动画替代。
box-shadow 消耗渲染性能，根本原因不是“写了阴影就卡”，而是它触发了离屏渲染（offscreen rendering）+ 高频重绘——浏览器必须为每个带阴影的元素额外分配一个合成层，并对阴影区域做高斯模糊计算。模糊半径越大、元素越多、动画越频繁，开销越明显。
blur-radius 超过 4px 就开始明显掉帧
模糊半径（blur-radius）是影响性能最敏感的参数，它直接决定高斯模糊的采样范围和计算量：
-
blur-radius: 2px：浏览器通常用查表法快速近似，几乎无感知 -
blur-radius: 6px：开始启用多遍卷积，CPU/GPU 负载上升约 40% -
blur-radius: 12px：在 iOS Safari 或低端安卓 WebView 中，可能触发软件渲染 fallback，动画掉到 30fps 以下
常见错误现象：
- 卡片列表滚动变卡顿，尤其在 iPhone SE 或 Redmi Note 系列上
-
hover动画出现“一帧延迟”或“跳变”，不是过渡不顺，是首帧没画出阴影
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 移动端默认上限设为
4px，桌面端谨慎突破8px - 用 rem/em 替代 px（如
box-shadow: 0 0.125rem 0.25rem rgba(0,0,0,0.08)），避免高 DPI 下模糊被放大渲染 - 不要为了“看起来更柔”盲目加
blur-radius，视觉柔和感更多靠rgba()的 alpha 值控制
overflow: hidden 是阴影消失的头号凶手
box-shadow 渲染区域默认在元素盒模型之外，一旦父容器设置了 overflow: hidden（或 auto 且内容未溢出），阴影就会被裁剪——这不是不渲染，是被暴力截断。
常见错误现象：
- 写了
box-shadow: 0 2px 8px rgba(0,0,0,0.1)却完全看不到 - 底部导航栏、弹窗、卡片容器加了阴影但只显示一半
- 在 Chrome DevTools 里看到 computed 样式中
box-shadow正常，但元素上就是空
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 用开发者工具检查目标元素及其所有父级的
overflow计算值，只要有一层是hidden或auto，就必须覆盖为visible - 不要用
!important硬顶，优先改结构：把阴影加在 overflow 容器的子元素上，或用伪元素绕过限制 -
position: fixed元素更要小心——它的 containing block 是 viewport，overflow: hidden很可能来自html或body
动画中直接 transition box-shadow 是性能陷阱
transition: box-shadow 0.3s 表面看没问题，实际每帧都在重绘整个阴影区域，无法被 GPU 加速。
常见错误现象：
- 悬浮动画卡顿、闪烁，尤其在长列表或复杂布局中
- iOS Safari 滚动时阴影“闪一下”再出现（repaint 延迟）
- Performance 面板里看到大量
Layout+Paint尖峰
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 把动画拆解：只动
transform和opacity，它们可触发硬件加速且不触发重排重绘 - 用伪元素预渲染阴影：
::before提前画好最终态阴影，hover 时只改opacity - 必须过渡阴影时，加
will-change: box-shadow，但仅限单个关键元素，别全局滥用 - 更稳妥的写法：
transition: transform 0.3s, opacity 0.3s，阴影变化用 class 切换而非渐变
真正容易被忽略的，是“这个阴影是否真有必要”。很多设计稿里的阴影，只是为了模拟 Figma 的默认图层效果，实际用户感知不到层级差异；而它带来的渲染成本、兼容性问题和维护负担，却实实在在落在每个设备上。
