选bem还是tailwind取决于团队协作、修改频率与维护阶段：bem适合长期协作与结构约束，tailwind适合快速开发与视觉一致性；混用时须规避权重冲突、scope污染与content配置错误。
选BEM还是Tailwind，不取决于“哪个更先进”，而取决于你项目里谁改样式、改得多频繁、改到什么程度——结构化命名解决的是协作与长期维护问题，原子化工具解决的是开发速度与视觉一致性问题。
什么时候BEM会明显拖慢开发节奏
BEM强制语义分层（block__element--modifier），在快速验证原型、营销页或内容型站点中反而增加认知负担。比如写一个临时弹窗，你得先想清楚是modal还是dialog，再拆出modal__header、modal__close，最后还得配CSS文件；而Tailwind直接写class="fixed inset-0 bg-black/50 flex items-center justify-center"就能跑通。
- 团队没有统一的组件库或Design System沉淀时，BEM容易退化成“起名游戏”，比如
card__title--big-red这种违反关注点分离的写法 - 设计师频繁调整间距、圆角、阴影等细节，每次都要改CSS文件并重新编译，无法在HTML里即时调试
- 项目用Vite或Next.js这类现代构建工具，但BEM类名没做scope隔离，仍可能被其他模块的
.title污染
Tailwind的class堆砌不是bug，是信号
当你在JSX里看到class="flex items-center justify-between p-4 border-b border-gray-200 rounded-t-lg bg-gradient-to-r from-blue-50 to-indigo-50 hover:from-blue-100"这种长串，这不是Tailwind的问题，而是你该封装组件的明确信号。
- 裸写原子类适合一次性页面、A/B测试分支、CMS模板等“样式即交付物”的场景
- 一旦同一组样式在3个以上地方复用，就该抽成React组件（如
SectionHeader），内部用Tailwind实现，对外只暴露语义props - 别用
@apply把原子类打包成新class——这既失去Tailwind的响应式前缀（如sm:p-6），又让PurgeCSS误判为未使用类而删掉
CSS优先级混乱常发生在BEM+Tailwind混用时
混用本身可行，但最容易翻车的地方是权重冲突：card__body的margin-top: 1rem会被mt-4覆盖，而开发者根本看不到报错。
- 必须禁用Tailwind的
!important：在tailwind.config.js中设important: false - BEM类只负责结构（
display、position、is-active状态）和嵌套关系，视觉表现（padding、rounded、shadow）全交给Tailwind - 避免给同一个元素同时写
card__body mt-4和.card__body { margin-top: 1rem; }——后者大概率失效且难以排查
content配置写错，Tailwind就等于没装
Tailwind不是“npm install完就能用”，它的类是否生效，完全取决于tailwind.config.js里的content字段有没有扫到你的模板文件。
- 常见失效：用React+TSX但
content只写了["./src/**/*.{js,ts}"]，漏了tsx后缀 → 所有JSX里的text-orange-600都不生效 - 用了
bg-[#165DFF]这种任意值语法，但content没覆盖到对应组件路径 → PurgeCSS直接删掉该类 - 正确写法必须穷举所有模板来源：
content: ["./src/**/*.{js,jsx,ts,tsx,html}"]，少一个后缀，就等于关掉一半能力
真正难的从来不是选BEM还是Tailwind，而是判断当前阶段要不要为“未来可能的修改”提前建约束——BEM是主动加锁，Tailwind是留好接口。多数人踩坑，是因为用BEM的思维写Tailwind，或用Tailwind的自由度去应付BEM该管的事。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
