box-shadow 卡顿源于每帧强制重绘，因旧引擎对 blur-radius＞4px 触发 cpu 软件渲染，导致帧率骤降；应严守 blur-radius≤4px、spread-radius=0、rgba() 透明度，并禁用其动画，改用 transform 或伪元素优化。
box-shadow 为什么一开就卡
它不是“慢”，而是每帧都强制重绘——浏览器必须为每个带 box-shadow 的元素额外分配合成层，再对阴影区域做高斯模糊计算。这个过程发生在 CPU Paint 阶段，无法走 GPU 合成线程，尤其在 Android 5–7 WebView 或 iOS Safari 9–12 中，blur-radius 超过 4px 就会触发软件渲染 fallback，实测帧率从 60fps 直接掉到 20fps。
常见错误现象：overflow: hidden 父容器 + box-shadow 子元素 → 整块区域放弃图层合并；@keyframes 动画 blur-radius → 每帧重绘，will-change 完全无效；用 hsla() 或 opacity 控制阴影透明度 → 触发整元素重绘而非仅阴影区域。
怎么写 box-shadow 才不拖垮渲染
核心是守住三个硬阈值：
-
blur-radius ≤ 4px：这是旧引擎的分水岭，超过后计算量呈 O(n²) 增长 -
spread-radius设为0：避免旧浏览器额外分配位图和 alpha 混合 - 透明度必须用
rgba()显式声明，比如rgba(0,0,0,0.08)，别用hsla()或外层opacity
移动端更激进：Android 平板上建议 blur-radius ≤ 2px；桌面端慎超 8px；老设备（如 MT6737）直接用 @media (max-width: 768px) and (-webkit-device-pixel-ratio: 1) 降级为 box-shadow: none。
box-shadow 动画卡顿的真正解法
别动画 box-shadow 本身——transition: box-shadow 0.3s 是性能陷阱。正确做法是把“变化”转移到浏览器能硬件加速的属性上：
- 用伪元素承载静态阴影：
.card::after固定画好box-shadow或渐变，主元素只做transform: translateY(-2px) - 需要“阴影变深”？加一层半透黑遮罩，用
opacity控制显隐，而非改box-shadow的 alpha 值 - 卡片悬停增强立体感？微调
transform: scale(1.02)+translateZ(0)创建独立合成上下文，比改阴影参数更稳 - 千万别写
will-change: box-shadow：它不生效，还白占 GPU 内存；真有用的是will-change: transform, opacity，且只在交互触发前一刻设置
什么时候该彻底放弃 box-shadow
不是所有场景都适合硬扛。当遇到以下情况，换方案比调参更高效：
- 列表项/卡片底部阴影：用
::after画线性渐变，background: linear-gradient(to bottom, rgba(0,0,0,0.1), transparent)，零模糊计算 - 搜索框描边类需求：预渲染
background-image: url("shadow-sprite.png")，运行时无开销 - 不规则轮廓（PNG 透明图、
clip-path切割）：此时filter: drop-shadow()是唯一解，但注意它会强制全元素重绘，慎用于滚动区域 - 文字投影：
box-shadow对行内内容效果差，drop-shadow天然适配，但别和transform同时用，否则层叠上下文截断阴影
真正容易被忽略的是：很多所谓“阴影动效”，用户根本感知不到 blur-radius 变化——他们只看到卡片上浮、颜色微调、边缘收紧。省掉那一行 transition: box-shadow，换成 transform + 固定阴影，既快又省电。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
