很多前端开发者在实际项目中常会遇到这样的疑问：明明给元素设置了 box-shadow，布局却莫名其妙地“被撑开”，或者阴影被父容器“裁剪”了。于是，一个流传甚广的误解随之产生——box-shadow 会影响盒模型的尺寸。
今天，我们来彻底厘清这个误区。简单来说，box-shadow 从不参与盒模型的计算，它仅仅是渲染层上的一次“贴图”操作，与元素的实际尺寸完全无关。
box-shadow 的绘制边界始终在 border box 之外
浏览器的渲染机制非常明确：它把 box-shadow 当作一个独立的视觉层级，绘制在元素的 border-box 边缘之外。也就是说，阴影既不会挤占 content 区域，也不会扩展 padding 或 margin 的空间。以下几个关键证据可以充分证实这一点：
getBoundingClientRect()返回的width和height中完全不包含阴影的扩展量。offsetWidth、clientWidth、getComputedStyle(el).width这些属性都无法获取任何阴影的尺寸信息。- 即使你写一个极端的
box-shadow: 0 0 0 100px #000来模拟超级粗的边框，元素的实际宽度和高度依然按照原始的width和height计算，不会增加。 - 父容器设置
overflow: hidden后阴影被裁剪，这并非因为“盒子变大了”，而是因为阴影绘制到了边界之外，被父容器无情地截断了。
为什么会产生“撑开”或“被截断”的错觉
既然阴影不影响尺寸，那为何我们常常感觉它“撑开了布局”或“被截断”呢？这些错觉基本都源于其他 CSS 行为与 box-shadow 叠加后产生的副作用：
- 父级裁剪：父容器如果设置了
overflow: hidden，它会主动裁剪任何超出自身内容区域的元素，包括子元素的阴影。这很容易被误以为子元素自身“越界”了。 - 边框的干扰：当元素同时设置
border且未使用box-sizing: border-box时，border本身就会增加盒子的实际尺寸。这种“撑开”效果是边框造成的，与box-shadow毫无关系。 - 内阴影的视觉覆盖：使用
inset内阴影（如box-shadow: inset 0 2px 8px #000）时，如果元素的padding设置得较小，文字就可能被内阴影遮住一部分，看起来像是布局塌陷了。 - 人眼视觉误差：深色阴影在浅色背景上会产生强烈的视觉膨胀感，导致我们判断元素边界时出现偏差。这纯粹是视觉错觉，并非真正的尺寸变化。
box-shadow 与 box-sizing 完全无关
这里需要特别强调：box-sizing 属性只控制 padding 和 border 是否计入 width/height 的计算，它对 box-shadow 的影响为零。
- 在
box-sizing: content-box模式下，阴影从更靠外的边界（即border的外侧）开始绘制。 - 在
box-sizing: border-box模式下，阴影仍然从同一个物理边界（即border-box的边缘）开始绘制，只不过这个边界因为border和padding被计入宽高而变得更靠内了。 - 无论哪种
box-sizing模式，阴影都不会改变边界的坐标，更不会触发导致性能损耗的重排（reflow）。
真正要检视的是上下文环境，而非 box-shadow 本身
因此，当下次再遇到阴影显示“异常”时，不要急着怀疑 box-shadow 本身，优先排查以下上下文因素：
- 父容器是否设置了
overflow: hidden或clip-path这类裁剪属性？ - 元素自身是否同时使用了
border-radius和inset内阴影，导致内阴影被圆角区域遮挡？ - 是否在
position: absolute的绝对定位元素上，错误地依赖阴影的视觉边界来做定位计算？请记住：阴影坐标始终基于border-box，而不是content-box。 - 有没有尝试用
filter: drop-shadow()替代？这个滤镜属性虽然也能生成阴影效果，但它走的是滤镜通道，行为与box-shadow不同，不仅会触发重绘，其计算路径也更复杂。
最后，一个最常被忽略的核心要点是：阴影虽然不是布局的一部分，但它确实会占用渲染像素。 如果你的设计要求阴影必须完整可见，正确的做法是给父容器预留足够空间（比如增加 padding 或 margin），而不是去调整 box-shadow 参数，试图让它去“适应”现有且可能不足的布局空间。理解了这一底层逻辑，很多布局上的困惑也就迎刃而解了。
