BEM 不适用于工具类，因其组件导向与工具类原子性冲突；应采用前缀（如u-）、数字缩写、色板编号等轻量命名法，仅封装高频纯视觉样式，禁用伪类、变量注入和子选择器，并通过@layer管控层叠。
为什么直接套用 BEM 命名写工具类会让人越写越乱
因为 BEM 本质是为「组件级样式」设计的，而工具类（如 mt-4、text-center）需要的是原子性、无上下文依赖、可自由组合——两者目标冲突。强行把 btn__icon--large 这类 BEM 结构塞进工具类，结果就是命名膨胀、语义错位、复用率反而下降。
- 工具类该回答“怎么渲染”，不是“这是什么组件”
- BEM 的
block__element--modifier结构天然带层级和意图，但flex、bg-red-50这类工具不需要知道它在哪个 block 里 - 真正该复用的是「命名逻辑」，不是 BEM 模板本身：用前缀区分职责（
u-表示 utility），用连字符分隔语义单元（u-mt-4），这才是可落地的“BEM 启发”
如何定义不打架的工具类前缀与命名规则
前缀不是装饰，是作用域隔离手段。没有前缀的 hidden 或 inline 极易和项目原有类、第三方库冲突；但前缀太长（如 utility-margin-top-4）又失去工具类应有的简洁性。
- 推荐统一用 1–2 字母前缀：
u-（utility）、t-（token），避免util-这种拼写冗余 - 尺寸值统一用数字缩写：
u-mt-1对应margin-top: 0.25rem，而不是u-mt-xs——后者需查映射表，破坏直觉 - 颜色类不绑定语义名（如
u-text-brand），而用色板编号：u-text-gray-700，否则换主题时要全局替换 - 禁止在工具类中写媒体查询变体（如
u-mt-4@md），响应式应由独立断点前缀承担：u-mt-4 u-mt-8@md
哪些 CSS 属性适合抽成工具类，哪些必须留在组件内
工具类只封装「纯视觉表现且跨场景高频使用」的声明。一旦涉及业务含义、条件逻辑或布局约束，就该收手——否则很快会写出 u-card-header-bg-hover-active-focus 这种反模式。
- ✅ 安全的：边距
u-mt-2、文字颜色u-text-blue-600、显示类型u-flex、阴影u-shadow-sm - ⚠️ 谨慎的：宽度
u-w-64（可能和栅格系统冲突）、定位u-absolute（脱离文档流需上下文判断） - ❌ 禁止的：伪类状态（
u-hover:bg-blue-500应交由 JS 控制类切换）、CSS 变量注入（--u-primary不是工具类，是设计 token）、子选择器（u-btn > u-icon违反原子性）
PostCSS 插件生成工具类时容易漏掉的关键配置
靠 postcss-preset-env 或 tailwindcss 自动生成工具类很省事，但默认配置常埋雷：比如未关闭 prefers-reduced-motion 相关类，或让 u-sr-only（screen reader only）被 PurgeCSS 误删。
立即学习“前端免费学习笔记（深入）”；
- 务必显式声明
content路径，否则 PurgeCSS 会清掉没在模板里“字面出现”的工具类（如 JS 动态拼接的u-mt-${n}） - 禁用
important选项——工具类不该靠!important覆盖组件样式，那是架构问题 - 若项目用 CSS-in-JS，别让插件输出
.u-* { ... }，改用:export导出 JSON 映射，供 JS 直接消费类名字符串 - 生成的类必须带
@layer utilities（CSS @layer），否则和组件样式层叠顺序不可控
工具类库最难的不是写多少类，而是守住「原子性」边界——只要一个类开始承担两个以上职责（比如既设 margin 又改 display），复用性就崩了一半。
