17370845950

唯一可靠方式是修改 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 屏下颗粒感明显
• 移动端卡片需更收敛的扩散半径，否则边缘模糊影响点击热区判断

如何让设计师和前端共用同一套阴影语义

在 tai

lwind.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

Tailwind 的阴影不是“开箱即用”的装饰开关，而是需要和设计系统对齐的接口。配置文件里那几行 boxShadow 定义，其实是你项目视觉契约的第一行代码。