bem修饰符叠加不会提升权重，失效主因是多个modifier修改同一属性或html漏写基础类；正确做法是各modifier控制不同样式维度且共存于同一元素。
为什么修饰符叠加会让样式失效而不是变强
BEM 的 --modifier 本身不提升选择器权重，.button--primary 和 .button 权重完全一样（都是 0-1-0）。所谓“叠加后更优先”，其实是错觉——真正导致样式失效的，是多个 modifier 同时修改同一属性（比如都设 background），或 HTML 中漏写了基础类名。浏览器按声明顺序覆盖，不是按类名数量。
- 常见错误现象：
class="button--primary--loading"单独写 → 缺button基础类，所有依赖 block 的样式全丢 -
.button--primary { background: blue; }和.button--loading { background: grey; }同时存在 → 后声明的生效，与是否叠加无关 - 用 SCSS 嵌套写
.button { &--primary { ... } &--loading { ... } }→ 编译后仍是两个独立单类名，无嵌套权重提升
哪些 modifier 写法会悄悄提高 specificity
真正抬高权重的，从来不是 -- 本身，而是你偷偷加进去的非 BEM 结构。这些写法表面像 BEM，实则破坏规则、引入高权重要素：
-
.button.button--primary→ 两个类名连用，权重变成 0-2-0，且违背“单类名选择器”原则 -
button.button--primary→ 标签名 + 类名，权重升到 0-1-1，一旦换成span就失效 -
.button--primary:hover→ 伪类让权重变成 0-1-1，还把交互逻辑和状态混在一起 -
.modal .modal__close--disabled→ 后代选择器直接回到 0-2-0，且脱离 block 上下文
如何安全地组合多个修饰符
多个 modifier 必须共存于同一元素，且各自控制不同维度的样式。关键不是“能不能叠”，而是“叠了之后有没有语义冲突”：
- 允许：
class="search-form__input search-form__input--disabled search-form__input--error"→--disabled控制opacity和pointer-events，--error控制border-color和outline - 禁止：
search-form__input--large--dark→ 这是嵌套 modifier，工具链无法识别，CI 会报错；应拆成两个独立类 - JS 拼接时务必保留基础类：
className={clsx('search-form__input', { 'search-form__input--disabled': isDisabled, 'search-form__input--error': hasError })} - 避免在 CSS 里用
@apply或composes:把多个 modifier 合并成新类 —— 会丢失可追溯性，DevTools 里看不到原始 modifier 来源
最容易被忽略的 modifier 陷阱
很多团队卡在 CI 报错却查不出原因，问题往往出在 modifier 的命名意图和实际用途脱节：
-
--big/--small→ 形容词不可控，“big”对 A 开发者是 24px，对 B 是 32px；应改用语义化尺寸：--size-xl、--size-m -
--loading→ 把 JS 状态直接塞进 class 名，导致样式层和逻辑层耦合；应统一用--is-loading，并确保所有相关样式只响应这个开关 -
.user-card__avatar--theme-dark→ theme 是页面级上下文，不应污染 block 内部；应由 wrapper block（如.theme-dark .user-card）控制，或用 CSS 自定义属性替代 - SCSS 中写
.button { &--primary { &--large { ... } } }→ 编译出.button--primary--large，违反 BEM 语法契约，stylelint-selector-bem-pattern会直接拦截
真正难的不是记住规则，而是在每次敲下 -- 之前，想清楚：这个 modifier 是否只描述当前 block 的视觉/行为变体？它会不会在别的上下文里被误复用？它的 CSS 属性是否和其他 modifier 完全正交？
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
