[!info] 关联笔记

• 所属：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. 删除 UI 时样式一起消失
4. 响应式/状态用变体前缀组合

与关注点分离

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

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

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

常见误区

[!warning] 常见误区：utility-first = 禁止组件化 相反，重复 UI 必须组件化；只是组件内部用 utility 表达。

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

工程实践

• 设计 token 进 theme
• 组件 props 映射到有限变体
• 动态 class 拼接要可扫描
• monorepo 配齐 content 路径

本节总结

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

自测题

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

参考答案

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