Modifier 必须表达语义化状态而非视觉实现，如 button--primary 而非 button--bg-red；须严格遵循 BEM 层级结构，禁止嵌套或断裂命名；多个 Modifier 应并列使用，不可链式叠加；名称需收敛可控，避免开放扩展。
Modifier 必须表达状态或变体，不能是视觉快照
写 button--red 是典型错误——它把颜色值直接塞进类名，一旦品牌色变更，就得全局搜索替换，且无法反推业务语义。真正该用的是 button--primary、button--danger 这类能明确回答“这个按钮在流程中起什么作用”的名称。
修饰符本质是接口契约：CSS 里定义 .button--primary { background: var(--color-primary); }，JS 控制是否添加该类，双方都只关心“是不是主操作”，不关心它此刻渲染成什么颜色。
- ✅ 推荐：
card--expanded、form--submitted、input--disabled、menu--horizontal - ❌ 避免：
button--bg-red、card--height-300、menu--flex-row（这些是样式实现细节，不是状态） - ⚠️ 警惕临时标签：
button--v2、header--new，它们无法长期维护，也破坏语义一致性
Block 和 Element 的 Modifier 命名规则不能混用
修饰符可以作用于 Block 或 Element，但命名结构必须严格对应其目标层级。写成 card__title--large 是合法的（Element + Modifier），但 card--title-large 就违反了 BEM 规则——双连字符 -- 只能紧跟在 Block 名或 Element 名之后，中间不能插入其他语义片段。
常见错误是把嵌套关系误当作修饰关系，比如想表达“标题里的大号图标”，结果写出 card__title__icon--large。这既违反 Element 不可嵌套原则，又让修饰符归属模糊。
立即学习“前端免费学习笔记（深入）”；
- 作用于 Block：
card--highlighted、search-form--compact - 作用于 Element：
card__title--large、search-form__input--error - 禁止写法：
card--title-large（结构断裂）、card__title__icon（Element 嵌套）、card__title--icon-large（修饰符名含冗余语义）
多个 Modifier 要并列使用，不链式叠加
BEM 不支持 button--primary--disabled 这种写法。它会导致选择器权重不可控、调试困难，且语义上变成“一种叫 primary-disabled 的新状态”，而实际只是两个正交状态的组合。
正确的做法是让每个 Modifier 各自独立、互不依赖，在 HTML 中并列书写：class="button button--primary button--disabled"。CSS 中分别定义：
.button--primary { /* ... */ }
.button--disabled { /* ... */ }
.button--primary.button--disabled { /* 可选：覆盖组合态样式 */ }- ✅ 正确：
button button--primary button--disabled - ❌ 错误：
button--primary-disabled、button--primary button--disabled--loading - ? 提示：React 中用
classnames管理多个 Modifier 更安全，例如cx('button', { 'button--primary': isPrimary, 'button--disabled': isDisabled })
Modifier 名称要可预测、可收敛，避免开放扩展
修饰符不是自由命名空间。一个 Block 的所有 Modifier 应在组件设计初期就约定好边界，比如 menu 的 Modifier 只允许 --horizontal、--vertical、--fixed，而不是随业务增长不断加 --mobile、--tablet、--print……那说明职责已经溢出，该拆新 Block 或换响应式方案了。
真正难的不是写对语法，而是判断“这个变化值不值得升格为 Modifier”。比如表单输入框的校验状态，input--error 合理，但 input--error-tooltip-visible 就越界了——tooltip 的显隐是交互逻辑，不该由 CSS 类控制。
复杂点在于：Modifier 的粒度常被低估。一个看似简单的 card--loading，背后可能涉及骨架屏、禁用交互、占位高度等多层含义。此时更稳妥的做法是拆解为 card--loading（整体状态） + card__body--skeleton（局部表现），保持每层 Modifier 职责单一。
