box-shadow从不参与盒模型计算，仅是渲染层的视觉贴图，不影响元素宽高、布局流及getBoundingClientRect()等尺寸属性；所谓“撑开”或“截断”实为overflow:hidden裁剪、border未配box-sizing等上下文问题所致。
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小于 10px，文字会被阴影盖住，像“布局塌陷” - 深色阴影在浅背景上造成视觉膨胀，边界判断出错——这不是尺寸问题，是人眼误差
box-shadow 和 box-sizing 完全无关
box-sizing 只控制 padding 和 border 是否计入 width/height，对 box-shadow 零影响：
立即学习“前端免费学习笔记（深入）”；
-
box-sizing: content-box下，阴影从更靠外的边界（border外侧）开始画 -
box-sizing: border-box下，阴影仍从同一物理边界（即border-box边缘）开始画，只是这个边缘更靠里了 - 无论哪种，阴影都不改变该边界的坐标，也不触发重排（reflow）
真正要检查的不是 box-shadow，而是它的上下文
当发现阴影“异常”时，优先排查这些地方：
- 父容器是否设置了
overflow: hidden或clip-path - 元素自身有没有
border-radius+inset导致内阴影被圆角区域遮挡 - 是否在
position: absolute元素上依赖阴影做定位——阴影坐标始终基于border-box，不是content-box - 用
filter: drop-shadow()替代过？它走的是滤镜通道，行为和box-shadow不同，会触发重绘且路径更复杂
最常被忽略的一点：阴影不是布局的一部分，但它会真实占用渲染像素。如果设计要求阴影必须完整可见，那就得给父容器留白，而不是调 box-shadow 参数去“适应”布局。
