CSS工具类命名应优先语义化而非简短，如mt-4明确表示上边距，而margin-2易引发歧义；间距宜用CSS变量+calc()动态生成，颜色需分基础色板与语义类两层，组合类应聚焦高频业务场景而非像素级复用。
为什么直接写 margin-2 类比写 mt-4 更容易出错
因为语义断裂。CSS 工具类不是越简短越好，而是要让开发者一眼看出作用方向和层级。比如 mt-4 明确表示「top margin」，而 margin-2 无法区分是上下左右、还是单边；更麻烦的是，当项目里同时存在 margin-2、m-2、mx-2 时，团队成员会反复查文档或翻源码确认含义。
推荐采用主流约定（如 Tailwind 的前缀体系），用固定前缀表达方向：
-
mt-：margin-top -
mb-：margin-bottom -
mx-：margin-left + margin-right -
px-：padding-left + padding-right
这样即使没有注释，也能靠命名推断行为，降低协作成本。
如何定义一套可扩展的间距工具类（非 Tailwind，纯 CSS）
关键不是“写多少个 class”，而是“怎么组织 scale 和单位”。硬编码 mt-1 到 mt-24 很容易失控。建议用 CSS 自定义属性 + calc() 控制基础单位，再通过 @each（Sass）或 CSS 层叠（原生）生成。
立即学习“前端免费学习笔记（深入）”；
例如用 Sass 定义一个间距 scale：
:root {
--space-unit: 0.25rem;
}
@function space($n) {
@return calc(var(--space-unit) * $n);
}
$spacings: (
1: 1,
2: 2,
4: 4,
8: 8,
12: 12,
16: 16,
24: 24
);
@each $name, $value in $spacings {
.mt-#{$name} { margin-top: space($value); }
.mb-#{$name} { margin-bottom: space($value); }
.mx-#{$name} { margin-left: space($value); margin-right: space($value); }
.py-#{$name} { padding-top: space($value); padding-bottom: space($value); }
}
这样后续只需改 --space-unit 或增删 $spacings 映射，就能全局调整所有间距值，不用逐个改像素。
颜色工具类必须绑定语义，不能只按色值分组
写 text-red-500 没问题，但若项目中出现 bg-red-500 表示「错误背景」、text-red-500 表示「成功文字」，就会造成认知冲突。工具类的颜色命名应优先反映用途，而非色板位置。
推荐两层结构：
- 基础色板类（仅用于设计系统维护）：
color-blue-50、color-blue-500—— 命名带color-前缀，不直接用于业务组件 - 语义类（开发日常使用）：
text-primary、bg-error、border-success—— 这些类内部用var(--color-primary)等 CSS 变量引用，方便主题切换
好处是：换主题时只需改变量值，所有语义类自动生效；排查样式问题时，看到 bg-error 就知道这是错误态，而不是去猜 bg-red-700 是不是该用在这里。
工具类不是越多越好，警惕“伪复用”
常见陷阱是把每个像素组合都做成工具类：比如 pt-1 pb-2 pl-3 pr-4 拆成四个类，看似复用，实则增加 HTML 冗余和渲染负担。真正该提取的是高频、稳定、有明确业务含义的组合。
例如：
- 卡片内边距统一用
p-card（对应padding: 1rem 1.5rem） - 表单控件垂直间距用
form-control-gap（对应margin-bottom: 0.75rem） - 按钮组内边距用
btn-group-inline（对应gap: 0.5rem+display: flex）
这类组合类不是为了“少写几个 class”，而是为了锁定设计规范。一旦 UI 走样，改一个 class 就全量修复，而不是在几十个模板里搜 mb-3 手动替换。
真正难的不是生成工具类，而是判断哪些该抽象、哪些该保留原子性——这得靠设计系统文档和前端与 UI 的持续对齐。否则工具类越多，越容易变成没人敢动的“祖传 CSS”。
