修饰符名必须语义化，不能是视觉描述；应表达意图而非颜色或尺寸值，如--primary、--disabled、--size-small，禁用--red、--blue、--100px等硬编码命名，且修饰符只能挂载在Block或Element上，不可嵌套或穿透。
修饰符名必须语义化，不能是视觉描述
看到 .button--red 或 .card--blue 就该警觉——这类命名把样式细节硬编码进类名，换主题时得全局搜索替换，违反 BEM 的可维护初衷。修饰符要表达“意图”，不是“颜色”或“尺寸值”。
常见错误现象：.header--black-bg、.input--100px、.btn--big
-
--primary、--secondary表达功能层级，而非具体色值 -
--small、--large表达相对尺寸意图，由 CSS 变量或统一 scale 控制实际像素 -
--disabled、--active、--loading直接映射组件状态，和 JS 事件/props 对齐 - 避免
--v2、--new、--temp这类临时标签，它们无法被长期维护
修饰符只能挂载在块或元素上，不能跨级或嵌套
.card__title--highlight 合法，.card--dark__title 或 .card__title__icon--spin 都非法。BEM 不支持修饰符“穿透”或“修饰修饰符”。
典型错误写法：.menu--horizontal__item--active（混淆层级）、.form__field--error__input（三层结构）
立即学习“前端免费学习笔记（深入）”；
- 块级修饰符影响整个块的外观或行为：
.modal--fullscreen - 元素级修饰符只作用于该元素：
.modal__close--hidden - 多个修饰符可并列，但需正交：
.button--primary--large--disabled可行；.button--primary--red冗余（--primary已隐含颜色语义） - 不要用修饰符替代 DOM 变更：需要加
aria-hidden或移除子节点时，不该只靠--visually-hidden类控制
布尔型 vs 键值型修饰符怎么选
两种都合法，但适用场景不同。关键看这个变体是否只有“开/关”两种稳定状态，还是存在多个离散取值。
容易踩的坑：把键值型当布尔型用，比如 .badge--status 却没定义 --status-success / --status-error，导致类名失去区分力
- 布尔型（推荐多数情况）：
--disabled、--expanded、--focused—— 有明确真/假含义，CSS 中通常对应display: none或opacity: 0.5等开关式样式 - 键值型（用于多态变体）：
--size-small、--theme-dark、--align-center—— 必须成组出现，且值域可控（如只允许small/medium/large） - 禁用模糊值：
--left（位置应由布局系统控制）、--top-banner（这是上下文，不是状态）
修饰符不改变 DOM 结构，也不承担逻辑职责
一个 --hidden 类，只该负责视觉隐藏；它不该触发数据清空、AJAX 中断或事件解绑。这些是 JS 层的事。
真实项目里常被忽略的一点：修饰符名一旦写进 HTML，就等于暴露了组件契约。如果某天你发现要给 .button--loading 加个 spinner 子元素，说明这个“加载态”已超出纯样式范畴——该拆出新块 .button-spinner 或改用属性控制（如 data-loading）。
- 修饰符变更必须可预测：JS 切换
--active时，不应同时手动增删tabindex或aria-pressed—— 这些应由组件封装内部处理 - 禁止修饰符之间互相依赖：
.input--error不该隐含.input--disabled的样式，二者逻辑独立 - 如果某个修饰符总要和另一个搭配出现（如
--error总带--focused），说明设计抽象有问题，应合并或重构状态机
