选BEM还是Tailwind取决于团队协作、修改频率与维护阶段：BEM适合长期协作与结构约束，Tailwind适合快速开发与视觉一致性；混用须规避权重冲突、scope污染与content配置错误。
选BEM还是Atomic CSS（如Tailwind），不看“哪个更潮”，而要看你团队改样式的人是谁、改得多频繁、改到什么程度——结构化命名解决协作与长期维护问题，原子化工具解决开发速度与视觉一致性问题。
什么时候BEM会明显拖慢开发节奏
BEM强制语义分层（block__element--modifier），在快速验证原型、营销页或CMS模板中反而增加认知负担。比如临时加个弹窗，你得先想清楚是modal还是dialog，再拆出modal__header、modal__close，最后还得配SCSS文件；而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误判为未使用类而删掉
BEM+Tailwind混用最容易翻车的三个点
混用本身可行，但权重冲突、scope污染和content配置错误是高频翻车现场。
立即学习“前端免费学习笔记（深入）”；
- 禁用Tailwind的
!important：在tailwind.config.js中设important: false - BEM类只负责结构（
display、position、is-active状态）和嵌套关系，视觉表现（padding、rounded、shadow）全交给Tailwind -
content配置写错，Tailwind就等于没装——必须确保它扫描到所有含原子类的模板文件路径，否则生成的CSS里压根没有mt-4这类类
真正难的不是选BEM还是Tailwind，而是识别出“这个按钮已经出现在7个页面里，但每个地方都手写了不同的px-4 py-2 rounded”——这种重复才是架构决策背后最该被揪出来的具体问题。
