BEM能将选择器特异性恒定为0-1-0，因其强制使用单类名（如.button__icon--loading），禁止空格、>、+等组合符及标签限定，一旦违反（如.button .button__icon）即升至0-2-0，破坏权重可控性。
为什么BEM能直接把选择器特异性压到0,1,0
浏览器计算CSS特异性时，类名选择器统一计为0,1,0；而一旦出现空格、>、+等组合符，就会叠加权重。BEM强制只用单个类名（如.button__icon--loading），天然避开嵌套带来的权重累加。你写.button .button__icon，特异性就变成0,2,0——哪怕只是多一个空格，也等于给后续覆盖埋下隐患。
- 所有BEM选择器必须是单类名，不能含空格或关系符
-
:hover、:focus这类伪类允许存在，它们的特异性是0,2,0，属于合理例外 - 避免用
!important或ID选择器补救，那说明BEM结构已失控
哪些BEM写法看似合规实则抬高了特异性
常见假合规：用.card:hover .card__title代替.card--hovered .card__title。前者在匹配时需实时验证父元素状态，触发额外计算；后者由JS切换类名，选择器仍是两个独立的0,1,0规则，性能更稳。
-
.form .form__input❌ —— 空格引入后代关系，特异性+1 -
button.form__submit❌ —— 标签名强化，破坏复用性且权重不变但语义断裂 -
.form__input.error❌ —— 多类名组合，.error不是BEM修饰符，无法被工具识别和隔离
如何用DevTools快速验证BEM是否真生效
打开浏览器开发者工具 → Elements面板选中目标元素 → 右侧Styles标签页里点开某条CSS规则 → 看选择器字符串是否纯为单类名。如果看到带空格或>的写法，就是构建或手写时漏了约束。
- Linux/macOS下可跑：
grep -r "\.[a-z]\+ \.[a-z]" src/css/扫出所有含空格的选择器 - Webpack项目建议启用
css-loader的exportOnlyLocals: true，防止意外注入全局嵌套规则 - CI中接入
stylelint-selector-bem-pattern，拦截.modal .modal__close这类违规
BEM遇上现代选择器时的特异性陷阱
:is()会继承参数中最高特异性，:where()恒为0,0,0。但BEM本就不该依赖它们来“降权”——真正的问题是：你为什么需要:is(.button--primary, .button--secondary)？这说明两个Modifier本该共用同一组基础样式，而不是靠选择器合并硬凑。
立即学习“前端免费学习笔记（深入）”；
- 优先拆解Modifier职责：让
.button--primary只管background，.button--large只管padding和font-size - 避免用
:where()包装BEM类名来“假装降权”，那等于放弃BEM的语义可读性 -
@scope虽新，但目前仅Chrome支持，且它不改变BEM类名本身的特异性逻辑，只划定作用域边界
class="header__nav-item"，但CSS却配了.header__nav .header__nav-item——这种错位不会报错，但会让整个BEM体系失去控制力。 
