bem通过block__element--modifier命名结构建立样式隔离墙，防止命名冲突与作用域污染；block为独立可复用组件，element为其直属组成部分，modifier仅描述状态变体，三者职责分明、不可混用或跨层嵌套。
直接用 .button、.header 这类泛化类名，UI错乱不是“可能”，而是“必然”——尤其在多人协作、微前端或接入第三方库的项目里。BEM 不是让类名变长的仪式，而是用命名结构本身建隔离墙。
为什么 .button 会炸掉别人的样式
CSS 没有作用域，浏览器只认选择器是否匹配，不关心它属于哪个组件。只要两处都写了 .button，后加载的规则就会覆盖前面的，且 DevTools 里只显示“被划掉”，不提示“谁干的”。常见现象包括：
-
margin突然变大，查到是某个index.css里的.button { margin: 0.5rem; } - 按钮文字颜色继承自远古
body规则，因为没写color，而另一份 CSS 里body { color: #666; }生效了 - 第三方库（如 Ant Design）的
.ant-btn和你写的.button在全局作用域下被同一份重置样式误命中
block__element--modifier 怎么真正起作用
关键不在“写得全”，而在“每个部分都有不可替代的语义职责”：
-
block必须是具体、独立、可复用的组件名，比如search-form，不能是form或search -
element用双下划线__连接，且必须依附于 block，比如search-form__input；禁止search-form__input__icon（超一级嵌套，应拆成新 block） -
modifier用双短横--，只描述视觉/行为变体，比如search-form--compact；不能写成search-form__input--disabled（元素不能自带 modifier，应是search-form__input search-form--disabled或另设search-form__input--disabled） - 禁止跨 block 组合：
.user-card .button是反模式，应写成.user-card__action-button
怎么和第三方组件库共存不打架
BEM 管不了别人家的 class，但能管住自己的影响范围：
- 别硬给第三方 class 加前缀（如
myapp-el-button），会破坏它内部的选择器链（比如.el-button.is-disabled失效） - 用 wrapper block 包一层：比如把
<el-date-picker></el-date-picker>放进<div class="form-field--date">，再写 <code>.form-field--date .el-input__inner - 在 Vue 中用
:deep()、React 中用:global()（CSS Modules 下）局部覆盖，但限定在 wrapper 内部 - 避免全局重置（如
* { box-sizing: border-box; }）影响第三方组件，改为.my-block * { box-sizing: border-box; } - 不改旧 class，但在旧组件外加 wrapper，比如把遗留的
<nav class="nav"></nav>改成<nav class="header-nav"></nav>，后续扩展用header-nav__item - 禁用 Sass 嵌套生成 BEM（如
.card { &__title { ... } }），手写全名更可控，调试时能直接搜到真实类名 - 用
stylelint-selector-bem-pattern在 CI 阶段拦截不合规写法，比 Code Review 更早卡住问题 - JS 动态添加的类也必须走 BEM，比如
el.classList.add('tooltip--visible')，而不是'active'或'show'
老项目迁移时最容易踩的坑
全量重命名既不可行，也不必要。真正要守住的是“新增代码”的入口：
最常被忽略的一点：BEM 的隔离效果完全依赖执行一致性。一个 .button--primary 和一个 .btn-primary 并存，就等于没隔离——不是名字长短的问题，是边界是否被所有人承认并遵守。
