唯一可靠方式是修改 tailwind.config.js 的 theme.boxShadow；需重定义默认值（如 md）并新增业务语义键（如 card），避免 CSS 覆盖冲突，确保设计与开发对齐阴影语义。
如何用 Tailwind 的 shadow- 工具类统一卡片阴影
直接改 tailwind.config.js 是唯一可靠方式。Tailwind 默认的 shadow-sm 到 shadow-xl 是固定值，无法通过 class 覆盖或“全局替换”，必须从配置源头重定义。
常见误区是试图在 CSS 中用 .card { box-shadow: ... } 覆盖，但这样会和 Tailwind 的工具类冲突，且破坏原子性原则——你得手动删掉所有 shadow-*，否则优先级混乱、调试困难。
- 修改
theme.boxShadow可覆盖全部内置 shadow 工具类语义 - 新增自定义 key（如
card）可保留原生工具类，同时加专属 class - 若项目已大量使用
shadow-md，建议只重映射，不删除原 key
module.exports = {
theme: {
extend: {
boxShadow: {
// 替换默认 md：更柔和、适配卡片
md: '0 4px 6px -1px rgba(0, 0, 0, 0.1), 0 2px 4px -1px rgba(0, 0, 0, 0.06)',
// 新增 card：专用于卡片，带轻微内阴影增强层次
card: '0 4px 12px -2px rgba(0, 0, 0, 0.1), 0 2px 4px -2px rgba(0, 0, 0, 0.05), inset 0 1px 0 rgba(255, 255, 255, 0.1)'
}
}
}
}
为什么不能只靠 shadow-lg 或 shadow-xl 统一使用
因为这些工具类对应的是固定数值：比如 shadow-lg 是 0 10px 15px -3px rgba(0, 0, 0, 0.1), 0 4px 6px -2px rgba(0, 0, 0, 0.05)，偏重、偏深，用在轻量卡片上会显得“下沉过重”，视觉失衡。
更关键的是，不同尺寸卡片（如小头像卡 vs 宽内容卡）对阴影的感知不同——统一用一个 class 强行套用，反而暴露设计断层。
立即学习“前端免费学习笔记（深入）”；
-
shadow-sm太弱，常被背景色吃掉 -
shadow-xl在浅底色上易显脏，尤其 Retina 屏下颗粒感明显 - 移动端卡片需更收敛的扩散半径，否则边缘模糊影响点击热区判断
如何让设计师和前端共用同一套阴影语义
在 tailwind.config.js 里用业务语义命名，比如 shadow-card-primary、shadow-card-hover，而不是仅靠 md/lg 这类抽象描述。
这样设计师给标注时写 “卡片悬停用 shadow-card-hover”，前端不用猜数值，也不用查 Figma 滴管取色——直接写 class 就行，协作链路变短。
- 命名体现用途：
shadow-input-focus、shadow-modal-backdrop - 避免数字后缀：
shadow-3不如shadow-card-subtle易维护 - 所有阴影 alpha 值建议控制在 0.05–0.12 之间，过高易显灰、过低不可见
兼容旧项目时怎么平滑迁移
不要一次性全局搜索替换 shadow-md → shadow-card。先用 !important 临时覆盖旧 class 行为（仅限过渡期），再逐步替换。
更稳妥的做法是：在配置中把 md 指向新值，保留语义不变，让团队无感升级；等代码清理完毕，再把旧 key 归档到 deprecated 注释区。
- 旧项目中
shadow-md可能已被用于按钮、输入框等非卡片元素，需逐个验证 - CI 中加入
grep -r "shadow-" src/ | grep -v "card"快速定位残留 - Shadow 值含
inset时，务必测试 Safari，旧版有渲染 bug
boxShadow 定义，其实是你项目视觉契约的第一行代码。 
