overflow-hidden会砍掉box-shadow是因为阴影绘制在border box外侧，而该属性裁剪的是padding box内边缘，属css规范行为；加padding可预留显示空间，但需满足padding≥阴影最大外延且父容器未隐式创建新层叠上下文。
为什么overflow-hidden会砍掉box-shadow
因为box-shadow绘制在元素的 border box 外侧，而overflow: hidden裁剪的是 padding box 的内边缘。阴影根本没机会“进入”内容区，刚画出来就被切了。这不是 bug，是 CSS 渲染规范的严格执行。你在 DevTools 里看到 shadow 值正常、computed 样式也对，但视觉上就是“断了一截”，这就是典型表现。
加padding能救，但必须算准值
加padding本质是把阴影落点“挪进”可显示区域，不是修复 bug，而是预留物理空间。但它只在两个硬条件满足时才生效：
-
padding值 ≥ 阴影最大外延距离：通常取blur-radius + abs(offset-y)和spread-radius三者中的最大值，再加 2–4px 余量 - 父容器没因
transform、opacity、will-change等隐式创建新层叠上下文（Safari 尤其敏感）
例如：box-shadow: 0 4px 12px rgba(0,0,0,0.15) → 至少要 padding: 16px（4 + 12 = 16）；若用了 box-shadow: 0 0 6px 4px #000 → padding 至少 ≥ 4px，否则边缘仍贴边。
Tailwind 中用padding的实操陷阱
直接写 class="p-4" 很容易翻车，尤其在现代布局中：
- Flex/Grid 容器加
p-4会压缩子项可用空间，可能触发换行、拉高行高或撑开轨道——特别是当用了grid-auto-rows: minmax(0, 1fr)或align-items: stretch时 - 卡片本身用了
w-full或grid-col-span-2？加p-4会挤内容，必须同步加box-border（即class="box-border p-4 w-full"） - 响应式下固定
p-4风险高：小屏过大、大屏又不够，不如优先查哪一层真正在裁剪
更稳妥的替代方案：flex 容器改用 gap 控制间距；grid 容器优先用 align-items: start + min-h-[100px]，完全绕过 padding 对轨道尺寸的影响。
真正该先查的不是padding，而是哪一层在裁剪
90% 的阴影消失问题，根源不在卡片本身，而在 DOM 链路上某个祖先节点。只要某层同时满足：position ≠ static + overflow: hidden / auto / scroll，它就成为包含块兼裁剪边界。
实操建议：
- 打开 Chrome DevTools → Elements → 逐层关闭祖先节点的
overflow属性，看哪一层关掉后阴影立刻恢复 - 检查 Layers 面板，确认目标元素是否被嵌套在某个 “stacking context” 里；Computed 面板搜
stacking context，有 “This element establishes a stacking context” 提示的就是真凶 - Tailwind 项目里常见“隐形凶手”：
overflow-hidden被 UI 库或重置样式自动加到body、main或section上，而不是你写的那层卡片父容器
加 padding 是最易上手的临时解法，但它掩盖了真实层级问题；一旦遇到 Safari 下加了 padding 还不显示，大概率是某层 transform: translateZ(0) 或 opacity 在背后悄悄建立了新层叠上下文——这时候删属性比调数值更快。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
