bem类名天然对应0-1-0特异性，因其强制仅用单类名选择器（如.button__icon--loading），不依赖父级嵌套；一旦引入空格、标签、泛义类等写法，特异性升至0-2-0并破坏语义与稳定性。
为什么BEM类名天然对应0-1-0特异性
BEM强制只用单类名选择器，比如.button__icon--loading，浏览器计算其特异性就是0-1-0——和.btn完全一样。它不靠堆叠父级来“赢”权重，而是靠命名本身锁定作用域。一旦你写.card .card__title，特异性立刻变成0-2-0，还引入DOM结构依赖，后续任何结构调整都可能让样式静默失效。
哪些写法会偷偷抬高Specificity破坏BEM初衷
这些看似“加强选择”的写法，实际是BEM的特异性破功点：
-
.search-form__submit:hover✔️（0-2-0，伪类允许，语义清晰） -
.search-form .search-form__submit❌（0-2-0，空格触发回溯，且违背BEM语义） -
button.search-form__submit❌（0-2-0，标签+类组合，框架换span就断） -
.search-form__input.error❌（0-2-0，Modifier必须绑定Block，单独加泛义类等于开后门）
Modifier叠加时样式覆盖错乱，其实是特异性没失控，而是规则冲突
.button--primary和.button--large同时存在却只生效一个，问题不在特异性（两者都是0-1-0），而在CSS声明顺序和属性重叠：
- 两个Modifier都设置了
background，后声明的必然覆盖前一个 - 应让
--primary管颜色、--large管尺寸，互不碰同一属性 - 检查所有Modifier是否重复定义
border、padding、font-size等布局相关属性 - 避免用
--full-width这种Modifier干布局活，交给工具类或独立布局规则更安全
第三方CSS入侵时，BEM的0-1-0反而成了防御底线
全局通配规则如body * { z-index: 0 !important }或.theme-dark * { opacity: .9 }会直接碾压所有0-1-0类名。这时BEM的价值不是“抗住”，而是“可定位、可隔离”：
- 用wrapper block包第三方组件：
<div class="form-field--date"><datepicker></datepicker></div> - 在CSS里写
.form-field--date .ant-date-picker，虽特异性升为0-2-0，但范围被严格限定在自己模块内 - 禁用
!important覆盖第三方样式——它会打断BEM的Modifier覆盖链，导致.button--disabled在某些环境下突然不灰显
真正难防的不是高特异性，而是构建后类名哈希、Modifier漏写基础类、或测试脚本误用.button--disabled单独匹配——这些都不是特异性问题，但会让BEM的0-1-0优势彻底归零。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
