Tailwind类名是受配置和工具硬性约束的原子语义系统，无需BEM；语义应由HTML结构和JS逻辑承载，混用BEM与Tailwind易致权重冲突、产物膨胀及理解成本上升。
Tailwind类名本身已是命名规范，无需额外BEM
很多人纠结“要不要在Tailwind项目里继续用BEM”，其实问题前提就错了。text-lg、flex-col、md:grid-cols-2 这些不是随意起的类名，而是整套经过严格设计的原子语义系统。它不靠开发者自觉遵守命名约定，而是靠配置文件 tailwind.config.js 和 ESLint 插件（如 eslint-plugin-tailwindcss）硬性约束合法类名范围。一旦写了 my-button 或 header__title--large，no-custom-classname 规则会立刻报错——这不是风格建议，是构建时拦截。
BEM的“语义”在Tailwind里被解耦到HTML结构和JS逻辑层
传统BEM强调类名承载组件结构（card__body）和状态（button--disabled），但在Tailwind中，这部分语义转移到了更合适的地方：
- 组件结构由HTML标签本身表达：
<article class="p-6"><h2 class="text-xl">...</h2></article>已隐含“卡片主体+标题”的层级关系 - 交互状态由JS控制类名组合：
className={`${baseClasses} ${isActive ? 'bg-blue-500' : 'bg-gray-200'}`，而不是靠button--active这种静态修饰符 - 响应式行为直接写在类名里：
sm:hidden md:block比header__nav--mobile更精确、无歧义
真正容易踩坑的是“混合使用”场景
团队里最常出问题的不是纯Tailwind或纯BEM，而是两者混用——比如在 Button.tsx 里一边写 class="px-4 py-2 bg-blue-500"，一边又加个 class="btn btn--primary"。这会导致：
- CSS权重冲突：
.btn--primary可能覆盖hover:bg-blue-600，调试时得反复切到 DevTools 查源码位置 - 构建产物膨胀：Tailwind 的
purge（现为content）机制只扫描模板中的类名，btn--primary若来自CSS文件，可能被误删或残留 - 新人理解成本翻倍：既要查Tailwind文档，又要翻团队BEM手册，还要判断哪个类该用哪种方式写
如果必须保留部分BEM类（例如对接老系统或第三方组件），唯一安全做法是把它们全部列进 whitelist 配置项，并确保不参与任何工具类组合。
立即学习“前端免费学习笔记（深入）”；
颜色/间距等设计Token仍需团队级约定
Tailwind没替代掉的，是设计系统层面的抽象。比如 text-red-500 是标准色，但“错误提示文字该用哪个红”这种决策，仍要靠团队定义 error-text 这样的语义别名（通过 @layer components 或 theme.extend.colors）。否则不同人会各自选 red-500、rose-600、danger-400，最终UI不一致。这个环节没法靠工具自动兜底，得靠文档和Code Review卡住。
