[!info] related notes

• 所属：Tailwind 基础 MOC
• 对象：Tailwind CSS
• 相关：工具类与关注点分离 · BEM · CSS Modules · CSS 学习路线

Tailwind Utility-First 心智模型

这个概念为什么出现

传统流程常是：先发明 .skuCardHeaderTitle，再在 CSS 文件填规则，再在多处覆盖。结果：

• 命名税高
• 死 CSS 不敢删
• 设计约束（间距/色板）被魔法数冲垮

utility-first 反转顺序：在标记处组合设计系统提供的约束，稳定 UI 再抽取组件。

[!abstract] 一句话理解 工具类是设计系统的 API；组件边界负责复用，而不是过早发明模糊语义 class。

最小示例

场景：列表里的低库存徽章

<span class="inline-flex items-center rounded-full bg-red-100 px-2 py-0.5 text-xs font-medium text-red-700">
  低库存
</span>

若该徽章在 12 处重复，下一步不是先造 .badge-danger-2，而是抽 <LowStockBadge /> 组件，内部仍可用 utility。

设计动机

1. 限制任意值，收敛到 scale
2. 降低上下文切换（HTML/CSS 来回）
3. 构建时按检测到的类生成 CSS；没有任何源码再引用时，对应工具类才可能不再输出
4. 响应式/状态用变体前缀组合

与关注点分离

经典“结构/表现分离”被误读成“HTML 不能有表现信息”。utility-first 主张：

• 分离的是可复用策略与魔法数，不是禁止在标记表达视觉约束
• 真正要分离的是：业务状态 vs 样式实现细节 vs 设计 token

详见 工具类与关注点分离。

常见误区

[!warning] 常见误区：utility-first = 禁止组件化 稳定重复的 UI 可以抽成组件或模板，内部仍使用 utility；不要只因少量类名相同就强制共用一个组件。

[!warning] 常见误区：不会 CSS 也能学好 Tailwind 布局/层叠/盒模型不懂，class 冲突无法解释。

工程实践

• 设计 token 进 theme
• 组件 props 映射到有限变体
• 动态选择用完整类名映射，避免拼接类名片段
• monorepo 核对扫描根目录：v3 配置 content；v4 使用自动检测及 source() / @source 补充范围

同一元素上冲突的工具类并非“HTML 中写在后面的获胜”：结果由生成 CSS 的顺序、层叠层、优先级等决定。最好按状态只选择一套冲突属性。

本节总结

先组合约束，再抽取组件；让 CSS 工程问题回到设计系统与结构，而不是命名发明竞赛。

自测题

1. 什么时候才值得从 utility 抽出 CSS 类/组件？
2. 为什么说 Tailwind 不能替代 CSS 学习？

参考答案

1. 出现稳定重复 UI 或需要语义化 API（按钮尺寸/语气）时。
2. 冲突、布局、继承、层叠仍是 CSS；Tailwind 只是表达层。

参考

• Styling with utility classes
• Source detection