bem更适用于强语义、高复用、样式深度耦合业务的场景，如多端复用的product-card；而utility-first适合快速迭代、低抽象需求的营销页或a/b测试页，两者可混合但需严守边界：bem管结构语义，utility仅作临时修饰。
什么时候BEM比Utility-First更合适
当组件需要强语义、高复用、且样式逻辑深度耦合业务含义时，BEM天然更稳。比如一个product-card在首页、搜索页、推荐弹窗里反复出现，每个地方都要控制card__price的对齐、card--featured的边框粗细、card__image的裁剪方式——这些不是“加个flex或rounded-lg”就能统一的，而是需要封装成可继承、可覆盖、带明确作用域的模块。
- 团队已有成熟组件库，且设计系统强调“块即契约”，此时BEM类名就是接口文档的一部分
- 后端模板直出HTML（如PHP/Java SSR），无法运行JS做原子类组合，必须靠预定义类名驱动样式
- 审计或合规要求类名可读、可追溯（如
user-profile__avatar--xs比w-6 h-6 rounded-full bg-gray-200更容易被非前端人员理解）
Utility-First在哪些场景会让BEM显得笨重
当你频繁调整间距、颜色、响应式断点，且这些调整不构成稳定抽象时，BEM会快速变成维护负担。比如一个按钮要“在移动端变宽、禁用时灰掉、悬停加阴影、焦点环偏移2px”，用BEM就得写button--mobile-fullwidth button--disabled button--hover-shadow button--focus-ring-offset-2，而Utility-First只需改几个类，不用动命名规则。
- 营销落地页、A/B测试页面、内部工具页：样式变更快、生命周期短、无长期复用价值
- 设计师直接改Figma再导出Tailwind类名的工作流已跑通，BEM反而增加翻译成本
- 项目已用CSS-in-JS（如Emotion），哈希类名已解决作用域问题，再套BEM只是徒增字符串长度
混合使用BEM和Utility类的真实约束
可以混，但必须划清边界：BEM管结构与语义，Utility类只用于临时修饰或响应式覆盖。比如<div class="card card--compact u-p-4 u-mb-6">中，<code>card和card--compact是模块主体，u-p-4和u-mb-6是布局微调——前者进组件CSS文件，后者走全局utility.css。
- 禁止在BEM element上直接挂utility类：
card__title u-text-xl❌；应改为card__title--large✅ - utility类名前缀必须显式声明（如
u-或is-），避免和BEM块名冲突（flex和flex-container就容易撞） - stylelint必须启用
stylelint-selector-bem-pattern，否则.card__header u-flex这种写法会绕过校验，埋下样式污染隐患
BEM的性能代价常被高估，但维护成本真实存在
浏览器匹配.card__body--highlighted确实比.highlighted略慢，但实际差异在纳秒级，现代引擎优化得足够好。真正拖慢的是人：当card__footer__link被误写成card__footer-link，它不会报错，但会漏掉样式；当card--loading需要同时影响card__image和card__meta，就得在两个地方写相同逻辑——这些才是BEM在中大型项目里最常卡住的地方。
别指望命名规范自动解决协作问题。它只提供检查锚点，真正的约束得靠stylelint-selector-bem-pattern配置+CI拦截+PR模板强制填“BEM变更说明”。否则三个月后，你会在card.css里看到.card-header-title和.card__header__title并存。
