中大型团队协作项目必须用bem，单人小项目或原型页面基本不需要；bem是防样式冲突的底线，适用于3人以上长期维护、组件复用率高、ui库对外提供或多模块并行开发场景。
中大型团队协作项目必须用BEM
单人小项目或原型页面基本不需要BEM——类名变长、书写成本上升，反而拖慢节奏。但只要项目涉及3人以上长期维护、组件复用率高、UI库需对外提供、或已有多个业务模块并行开发，BEM就不是“可选”，而是防冲突的底线。
典型场景包括：企业级后台系统（如CRM、ERP）、多端统一UI组件库、SaaS平台的可配置主题体系。这些项目里，.header__logo--small 比 .logo-small 能立刻锁定它属于 header 块，不会和另一个 footer__logo--small 冲突，也不依赖父选择器层级来限定作用域。
BEM在React/Vue组件中怎么落地不别扭？
很多人在JSX里写 className="card__title--highlight" 觉得冗长，其实是没配合构建工具。真实高效做法是：
- 用
clsx或classnames动态拼接修饰符，比如clsx('button', `button__icon--${size}`) - 在组件顶层定义块名常量，如
const BLOCK = 'user-profile'，后续所有类名基于它生成 - 避免在子组件里硬写完整BEM名，改用
props.className接收外部传入的修饰符类名
关键不是“手写所有类名”，而是保证最终渲染出的 class 字符串符合 .block__element--modifier 结构。Sass 的 @use + meta.load-css 也能自动注入命名空间，减少重复。
前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。
为什么不能只用单下划线或中划线代替双下划线？
因为 .menu-item 和 .menu_item 都无法区分「menu 这个块的 item 元素」和「一个叫 menu-item 的独立块」。BEM 强制用 __ 和 -- 是为了语法上可解析——工具链（如 PostCSS 插件、CSS Modules 的命名转换）能无歧义地提取 block 名、识别 element 层级、过滤 modifier 状态。
常见踩坑：
- 写成
.card-title，结果被当成新 block，导致样式无法复用或覆盖失效 - 把修饰符写成
.button__primary（漏了--），CSS 选择器匹配失败，状态切换不生效 - 在 Sass 中用
&__content嵌套时，忘了外层 selector 必须是.block，否则生成的 CSS 类名会错位
和CSS Modules、Tailwind对比时BEM的真实定位
BEM不是“过时方案”，而是解决不同问题的工具：CSS Modules 主要靠编译期哈希隔离作用域，但类名语义丢失；Tailwind 用原子类组合，可读性差、难以全局控制变体逻辑。BEM 在这两者之间卡了一个关键位置——它不阻止你用 tw-xxx 做快速布局，但核心组件结构（如 form-control__input--error）仍保留明确语义和可继承性。
真正容易被忽略的是：BEM 的价值不在“写出来那一刻”，而在“半年后别人接手改 search-form__submit--loading 时，不用翻三页代码就能确认它只影响提交按钮的加载态，且不会动到 search-form__input 的边框”。这种确定性，在迭代频繁的业务系统里比节省几个字符重要得多。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
