box-shadow 不影响布局，因其仅作用于视觉层、不参与文档流计算，不改变元素尺寸（如 offsetwidth、getboundingclientrect），也不会增加实际占用空间。
box-shadow 为什么不会影响布局
因为 box-shadow 是绘制在元素「视觉层」上的效果，不参与文档流计算，也不改变元素的 offsetWidth、getBoundingClientRect() 的尺寸结果。它就像给盒子贴了一层半透明贴纸，贴纸再大，盒子本身还是原来那么大。
常见错误现象：box-shadow 看起来“压到隔壁元素”了，就以为是阴影占空间——其实是阴影溢出后盖住了相邻元素，不是它抢了位置。
- 阴影完全由渲染引擎在绘制阶段叠加，不影响 layout、paint 的尺寸判定
- 即使设置超大模糊值（如
box-shadow: 0 0 100px rgba(0,0,0,0.3)），clientHeight和scrollHeight依然不变 - 如果父容器设置了
overflow: hidden，过大的阴影会被裁剪，这不是“被挤出去”，而是被剪掉了
什么时候 box-shadow 看起来像占了空间
真正造成“占位错觉”的，通常是伴随阴影一起出现的其他样式或结构问题。
使用场景：卡片列表中加阴影后行距变小、文字被遮挡、Flex 项错位。
立即学习“前端免费学习笔记（深入）”；
- 误加了
margin或padding来“模拟”阴影留白，结果是 margin 在占空间，不是 shadow - 父容器没有设置
overflow: visible（默认就是 visible，但有时被重置），阴影被意外裁切，导致视觉突兀 - 用了
transform: scale()或filter: drop-shadow()混用，后者会触发新的层叠上下文并可能影响绘制边界
box-shadow 和 filter: drop-shadow() 的关键区别
box-shadow 只作用于元素自身的盒模型轮廓；filter: drop-shadow() 则基于元素最终渲染的 Alpha 通道（即实际像素形状）投射阴影，会跟随 border-radius、clip-path 甚至透明区域变化。
性能 / 兼容性影响：两者都硬件加速，但 filter 触发 Paint，对复杂图形开销略高；IE 完全不支持 filter，而 box-shadow IE9+ 就支持。
-
box-shadow: 0 2px 4px rgba(0,0,0,0.2)→ 始终按矩形盒投射 -
filter: drop-shadow(0 2px 4px rgba(0,0,0,0.2))→ 圆角图片只在圆角边缘有阴影，锯齿处也贴合 - 如果元素有
opacity: 0.99，box-shadow不受影响，但filter可能轻微改变整体渲染质量
需要“预留阴影空间”时的务实做法
虽然 box-shadow 自身不占空间，但 UI 上常需为视觉平衡留白——这时得靠真实占据空间的样式来实现，不能指望 shadow 自己撑开。
可给出简短示例：
/* 正确：用 padding/margin 主动留空 */
.card {
box-shadow: 0 4px 12px rgba(0,0,0,0.15);
padding: 16px; /* 内边距防内容贴边 */
margin: 16px; /* 外边距防阴影盖邻项 */
}
<p>/<em> 错误：试图用 shadow 的 spread 负值“缩进”，没用 </em>/
.card-bad {
box-shadow: 0 4px 12px -4px rgba(0,0,0,0.15); /<em> spread -4px 不会缩小盒子，只让阴影内收 </em>/
}- spread 值只控制阴影本身的扩张/收缩，不影响元素盒尺寸，也不解决遮挡问题
- 响应式中建议用
calc()配合rem控制 margin，避免阴影在小屏上“溢出屏幕” - 如果用 CSS-in-JS 或动态生成 shadow，注意不要把字符串拼错成
boxshaddow——这种低级错误真不少见
最易被忽略的一点：当元素有 position: absolute 且未设 top/left，它的 box-shadow 仍按静态位置渲染，但父容器若 overflow: hidden，阴影可能直接消失——这时候不是 shadow 变了，是它被裁了。
