Utility-first CSS（如Tailwind）通过原子化类名（如bg-blue-500）消除命名负担，核心是“类名即样式”；应避免封装语义类、滥用@apply，并用prefix或shortcuts管理命名空间，提升可维护性与协作效率。
用 utility-first CSS 框架替代手写语义类名
不用再为 btn-primary-blue-hover-shadow 这种名字纠结。Utility-first（如 Tailwind、Windi、UnoCSS）把样式原子化，直接用 bg-blue-500、hover:shadow-md 表达意图，类名即样式，起名负担归零。
常见错误是硬套 Bootstrap 思维：试图封装 my-btn 类再复用——这反而退回到语义类名的老路，失去 utility 的灵活性和可组合性。
- 真正省力的前提是接受“类名 = 样式声明”，不抽象、不封装、不命名业务含义
- 项目初期就定好间距/颜色/字体等设计 token，否则
mt-2和mt-3会用得毫无章法 - 避免在 HTML 中堆砌 10+ 个 utility class，超过 6–7 个时建议抽成
@layer components或使用apply（Tailwind）或uno:xxx（UnoCSS）做局部聚合
Tailwind 的 @apply 不是“起名权回收”，而是约束组合边界
@apply 看似让你重新获得命名权，但它本质是 CSS 预处理器级别的组合语法，不是语义抽象。滥用它等于绕开 utility 的设计哲学，又掉回维护一堆自定义类的坑里。
典型误用：@apply bg-gray-100 border border-gray-300 rounded p-2 text-sm 封装成 .input-field——结果这个类只在一处用，还锁死了所有属性，后续要改圆角就得动 CSS 文件，而不是直接改 HTML 里的 rounded-lg。
立即学习“前端免费学习笔记（深入）”；
-
@apply只应在组件级复用高频组合（如按钮变体、卡片基础样式），且必须限制在@layer components中，避免污染全局 - 一旦发现
@apply类被用于不同语义场景（比如.card既用在文章列表也用在用户设置页），说明它已开始承担语义职责，该停手了 - 注意
@apply不支持响应式前缀（如@apply md:flex无效），要用@screen或拆成多条规则
自定义 class 名称仍存在，但只出现在极少数必要位置
完全摆脱类名？不可能。路由组件、布局容器、第三方组件包裹层这些地方，仍需有意义的 class，比如 app-layout、user-profile-card。它们不表达样式，只锚定结构与作用域。
关键区别在于：这些 class 不参与样式定义，只用于 JS 选择器、CSS Scoped、或 BEM 命名空间隔离。Tailwind 的 prefix 配置或 UnoCSS 的 shortcuts 才是管这类需求的工具。
- 配置
prefix: 'tw-'后，所有 utility class 变成tw-bg-blue-500，避免和你写的header-nav冲突 - 用
shortcuts（UnoCSS）或theme.extend.container（Tailwind）定义设计系统级常量，而非业务类名 - 禁止用自定义 class 覆盖 utility 行为，比如写
.btn { @apply bg-red-500; }再在 HTML 里写class="btn hover:bg-red-600"——hover 效果会失效，因为 CSS 优先级被破坏
开发体验提升的关键不在“少写类名”，而在“删类名不心虚”
当改一个按钮颜色只需把 bg-blue-500 换成 bg-emerald-500，而不是打开 _buttons.scss 找 $primary-color、改变量、清缓存、再验证所有按钮是否错乱——这才是真正的效率。
容易被忽略的是：utility 类名的可读性依赖团队对设计系统的共识。如果设计师给的色板叫 “Primary / Success / Warning”，而你代码里写 bg-cyan-400，协作时照样卡壳。
- 务必同步维护一份轻量文档，说明
text-xs对应几号字体、space-y-4是多少像素，别指望所有人背配置 - CI 流程中加入
tailwindcss-classnames或unocss-preset-mini的 lint 规则，拦截非法类名（如bg-900） - 不要为了“统一”强行禁用内联
style——动态颜色、计算尺寸等场景，style="background: var(--dynamic-bg)"比生成一堆 utility 更干净
