BEM类名权重恒为0-1-0导致样式覆盖仅依赖声明顺序和作用域匹配，易因HTML漏基础类、CSS顺序错乱、第三方组件侵入或构建配置偏差而失效。
为什么BEM类名的特异性“一致”反而是个问题
很多人发现写完 .card__title 和 .card__title--large，后者却没生效——不是权重不够，而是它们权重完全一样（都是 0-1-0），浏览器只看谁在 CSS 文件里声明得更靠后。这种“公平竞争”在多人协作或引入第三方样式时，极易失控。
常见错误现象：.button--primary 被后面加载的 .button 规则覆盖；或者 Vue 的 scoped 样式里写了 .form__input--error，但弹窗挂到 body 下后，.form__input--error 根本不匹配任何元素。
- 所有 BEM 类选择器权重恒为 0-1-0，不因命名长度或双下划线增加
- 冲突不靠“谁更重”，只靠层叠顺序（source order）和作用域是否命中
- 一旦 HTML 缺基础类（如只写
class="button--primary"漏了button），样式直接失效
如何让 Modifier 真正生效而不被基础类覆盖
Modifier 不是独立样式单元，它必须依附于 Block 或 Element。生效的前提是：HTML 中同时存在基础类 + Modifier 类，且 CSS 规则顺序正确。
- ✅ 正确写法：
class="button button--primary"+ CSS 中.button在前，.button--primary在后 - ❌ 错误写法：
class="button--primary"单独使用（无button），或.button--primary声明在.button之前 - JS 动态添加时必须校验基础类：
el.classList.contains('button') && el.classList.add('button--primary') - 多个 Modifier 同时用，要避免改同一属性：比如
.button--primary和.button--loading都设background，后声明的那个必然赢
当 BEM 遇到第三方组件（如 Ant Design、Element Plus）
你不能改 .ant-btn 的类名，但可以控制它的作用域边界。BEM 不是封闭系统，而是责任划分工具。
立即学习“前端免费学习笔记（深入）”；
- 别写
:deep(.ant-btn)（Vue）或.my-block .ant-btn—— 后者虽破 BEM 原则，但比空格后代选择器更可控、权重仍为 0-2-0 - 包一层 Block 容器：
<div class="my-form"><DatePicker /></div>，再写.my-form .ant-input - 禁用
button.ant-btn这种标签+类组合：框架可能用span渲染按钮，样式立刻断裂 - 构建阶段加统一前缀（如
myapp-ant-btn）比手写穿透规则更稳定，且不依赖运行时
哪些操作会悄悄破坏 BEM 的 0-1-0 权重承诺
BEM 的权重稳定性不是命名对了就自动成立，它依赖开发链路每个环节的配合。
-
css-loader配置中localIdentName若去掉双下划线（比如配成[name]_[local]），.menu__item可能被转成.menu_item，直接失去 BEM 语义和隔离性 - SCSS 嵌套写法
.card { &__title { } }没问题，但若写成.card { .title { } }，编译后是.card .title，权重升至 0-2-0，且结构一动就失效 - 用
!important强行覆盖第三方样式，等于主动切断 BEM 的 Modifier 覆盖链——后续任何状态切换（如--disabled→--success）都会不可控 - 全局通配规则（如
body * { z-index: 0 !important; }）会直接废掉所有 BEM 的z-index控制，这不是 BEM 失效，是你没拦住上游污染
BEM 的权重一致性是个精密约定，不是魔法。它真正脆弱的地方不在命名，而在 HTML 是否严格共存、CSS 是否按序声明、构建配置是否守约、以及你有没有在某个深夜为了赶工偷偷加了一行 div .card__title。
