BEM与Tailwind不是互斥而是分层协作：BEM定义语义契约（如order-card__pay-button--processing），Tailwind提供视觉原子（如p-3、bg-blue-500）；前者用于业务组件、SSR、跨角色协作与主题控制，后者适用于布局、响应式及临时调试，混用需严守“BEM表身份、Utility管样式”的边界。
纯业务组件优先用 BEM，通用视觉规则（间距、颜色、圆角）交给 Utility-First；二者不是互斥方案，而是分层协作关系。
什么时候该用 BEM 而不是 Tailwind 类名
BEM 是语义契约，Tailwind 是视觉原子。当你需要表达“这是订单卡片的支付按钮”，而不是“这是带阴影、蓝色背景、12px 内边距的按钮”时，BEM 就不可替代。
- 组件需被 SSR 直出或微前端子应用注入 HTML 时，
order-card__pay-button--processing是唯一可依赖的类名，bg-blue-500 p-3 shadow-sm在 JS 未执行前无效 - 团队中存在非前端角色（如后端模板工程师、UI 设计师）需阅读/审计样式逻辑，BEM 类名自带业务上下文，
user-profile__avatar--xs比w-6 h-6 rounded-full更易对齐需求 - 要支持主题切换或运行时状态接管（比如通过 JS 切换
theme-dark并批量影响所有--disabled修饰符），BEM 的状态粒度更可控
Utility-First 适合塞进 BEM 哪些位置
Utility 类不该出现在组件主结构里，但可以安全用于布局容器、响应式断点、或临时调试场景。
- 在
.product-grid这类布局 Block 内部，用grid-cols-2 md:grid-cols-4 gap-4管理网格结构，而非写一堆product-grid__item--col2 - 组件根元素上加
max-w-screen-md mx-auto控制宽度，这类与业务语义无关的约束，硬套 BEM 反而模糊焦点 - 开发阶段临时加
bg-red-100 border-l-4 border-red-500标记某个 Element 方便定位，上线前删掉——Utility 是胶带，不是钢筋
BEM 和 Utility 混用时最常踩的坑
不是“能不能混”，而是“在哪一层混”。错位使用会让两类规则互相瓦解。
立即学习“前端免费学习笔记（深入）”；
- 在
button--primary里又写text-white bg-indigo-600 px-4 py-2：Utility 覆盖了 BEM 的状态语义，button--disabled无法再统一控制背景色 - 把
u-mt-4（utility margin top）当form__header--spaced用：修饰符本应描述业务状态（如--compact），而不是视觉副作用 - 在 Sass 中用
@extend .u-p-2继承 utility 类：构建后会把所有用到u-p-2的地方都塞进 button 的 CSS 规则里，权重爆炸且不可预测
真正难的不是选哪套方案，而是守住分界线：BEM 定义“它是什么”，Utility 定义“它怎么排布”。一旦开始用 card__body--p-6，就等于把布局责任塞给了语义层，后面谁都不敢动这个 padding。
