为什么BEM能减少样式冲突
BEM（Block-Element-Modifier）不是魔法，它靠命名规则强行切断CSS选择器的隐式依赖。传统写法里.header .nav a这种嵌套选择器，一旦组件挪位置、父级加类、甚至只是引入第三方UI库，就可能意外覆盖或被覆盖。BEM强制每个类名自包含：header__nav、header__nav-link、header__nav-link--active——没有层级假设，不依赖DOM结构，自然不怕嵌套变动或第三方干扰。
怎么写才算合规的BEM类名
三个部分必须严格用双下划线__和双连字符--分隔，中间不能有空格或驼峰：
-
block：独立功能单元，比如button、card、search-form -
block__element：属于block的子节点，不可单独存在，如button__text、card__title -
block--modifier：block的变体状态，如button--primary、card--compact - 禁止出现
button__icon--large这种“element修饰element”的写法；应改为button--icon-large或拆成新block - 修饰符不改变结构，只改外观；状态类（如
is-disabled）可共存，但不属于BEM原生体系，建议统一前缀避免混用
实际项目中容易踩的坑
最常出问题的地方不在命名，而在文件组织和复用逻辑：
- 把
button.css写成一个大文件，塞进所有button--primary、button--outline、button__icon……结果每次改按钮图标都要翻几百行。正确做法是按功能拆：button.css（基础）、button_theme.css（主题）、button_size.css（尺寸） - 用
@import在CSS里拼接BEM模块，导致最终CSS顺序错乱，--small覆盖了--large。现代项目优先走构建工具（PostCSS、Webpack）做模块合并，而非CSS原生@import - 在JS里拼接类名：
el.className = 'button button--' + type——漏掉空格或拼错大小写，浏览器不会报错，但样式就丢了。改用classList.add('button--' + type)更安全 - 过度BEM化：给
<span>文字</span>硬套text__content。BEM适用于有明确边界和复用意图的组件，不是每个标签都要命名
和CSS-in-JS或Tailwind比，BEM还值得投入吗
值不值，取决于团队规模和交付节奏：
立即学习“前端免费学习笔记（深入）”；
- 团队超5人、维护周期超1年、有多个业务线共用组件库——BEM的命名约束力远胜自由发挥。查一个
modal__close-button，立刻知道它属于modal块，不会误动dialog__close-button - 用Tailwind？可以，但得接受“样式逻辑散落在JSX里”，审查样式变更需全局grep；BEM把样式契约写死在类名中，设计稿改个圆角，你只改
button--rounded一处 - CSS-in-JS（如Emotion）能彻底隔离作用域，但服务端渲染时生成的类名不可预测，调试DevTools里一堆
css-1a2b3c，排查真实业务问题反而更慢 - 真正难的是习惯——不是写不对BEM，而是写一半又回到
.user-info h3这种老路。建议用ESLint插件stylelint-selector-bem-pattern在提交前卡住
名字写对只是起点，BEM真正的成本在于所有人持续遵守同一套语义契约。没人检查时，card__header-text很快就会变成card__headerText，然后是cardHeaderTxt……最后又回到冲突的老路上。
