BEM命名能直接减少CSS类名冲突，因其强制样式作用域限于模块内，所有类名按block__element--modifier格式组织，如header__logo--dark与footer__logo--light天然隔离，避免同名覆盖。
为什么BEM命名能直接减少CSS类名冲突
因为BEM强制把样式作用域限制在模块内，避免全局污染。一个组件的所有样式都以block__element--modifier形式组织，比如header__logo--dark和footer__logo--light天然隔离，不会因都叫logo而互相覆盖。
常见错误是把__element写成嵌套层级，比如用.card .title代替card__title——这会让样式依赖HTML结构，一旦DOM微调就失效；也违背BEM“类名即语义”的设计初衷。
- 所有样式必须通过显式类名触发，禁用标签选择器、ID选择器、属性选择器（如
[type="submit"]） - 块名（block）要语义清晰，优先用业务词而非视觉词，比如用
product-card而不是box - 修饰符（modifier）只表达状态或变体，不描述位置或父级关系，禁止写
card__title--in-sidebar
如何让新成员30分钟内看懂一个组件的样式结构
关键不是教BEM规则，而是统一文件组织+命名映射。每个BEM块对应一个独立文件：button.css里只写button、button__icon、button--primary相关样式，且文件开头加注释说明该块的用途和可用修饰符。
示例注释：
立即学习“前端免费学习笔记（深入）”；
/* * @block button * @description 主操作按钮，支持尺寸/主题/加载态 * @modifiers: --small, --large, --secondary, --loading */
新成员打开button.css就能立刻知道：这个组件叫什么、能做什么、有哪些变体、哪些类名可直接复用——不需要翻HTML找上下文，也不用猜btn--lg是不是和button--large等价。
- 禁止跨文件定义同一block的样式，比如
form.css里写button__text - 如果组件有子组件（如
dropdown里含menu），子组件仍需独立block名，不写dropdown__menu，而应为menu（除非它只在dropdown内使用且无复用可能） - 工具链建议启用
stylelint-bem-naming，实时校验命名格式，比Code Review更早拦截错误
BEM与现代CSS方案（CSS Modules / CSS-in-JS）是否冲突
不冲突，但目标不同：BEM解决的是“人类协作时的可读性”，CSS Modules解决的是“运行时样式隔离”。你可以同时用Button.module.css配合BEM命名，比如导出button、button__label等变量。
容易踩的坑是混淆作用域层级。例如React中写了className={styles['button__icon']}，却在JSX里又加了一个icon类名——这会让样式来源不可追溯，破坏BEM“一个类名=一个职责”的约定。
- CSS Modules中，BEM类名必须100%通过
styles.xxx注入，禁止硬编码字符串"button__icon" - 使用
@apply（Tailwind）时，不要把BEM类名当工具类混用，比如@apply button__icon会丢失语义，应只用于基础原子类 - 构建工具如PostCSS可配
postcss-bem自动补全父级块名，但需确认团队是否接受隐式生成，否则反而增加理解成本
BEM真正难的不是写对名字，而是坚持让每个类名都回答三个问题：它属于哪个功能模块？它在模块中扮演什么角色？它当前是什么状态？漏掉任意一个，协作成本就会悄悄回升。
