bem修饰符不能单独使用，必须依附于block或element，否则样式失效、语义丢失、工具链异常。应禁用全局状态类，用具体块修饰符如button--disabled，并通过工具函数校验主体存在。
修饰符单独使用会导致样式失效或错位
直接写 .disabled 或 .large 这类类名，CSS 选择器根本匹配不到任何 BEM 主体，样式自然不生效。BEM 的 --modifier 是依附型语法，不是独立语义单元——它必须和 block 或 block__element 共存才有意义。
常见错误现象：
- 在 HTML 中写
<button class="button--primary disabled"></button>，结果.disabled规则没定义，按钮失去预期状态样式 - 团队协作时有人复用
.hidden到非 BEM 组件上，导致全局冲突或覆盖（比如和modal__content--hidden行为不一致） - 构建工具（如 PostCSS 插件）按 BEM 模式提取类名时，漏掉孤立修饰符，无法做原子化打包或 tree-shaking
脱离块的修饰符会破坏语义锚点
BEM 不是字符串拼接游戏，button--disabled 和 input--disabled 虽然都含 --disabled，但它们控制的是不同组件的状态逻辑和可访问性行为。一旦把 --disabled 抽成通用类，就等于抹掉了“谁被禁用”的上下文。
实操建议：
- 禁用全局
.is-disabled、.has-loading这类抽象状态类；改用button--disabled、form__submit--loading - 如果多个块共用同一视觉表现（比如统一禁用灰度），优先用 CSS 自定义属性控制：
--state-disabled-color: #999，而非共享类名 - JS 中判断状态时，别写
el.classList.contains('disabled')，而应查el.classList.contains('button--disabled')—— 避免误判
为什么不能用 button--primary--disabled 这种双修饰符？
这种写法看似省事，但违反了 BEM 的扁平层级原则：修饰符之间不应有依赖或顺序关系。它会让 CSS 选择器权重升高、调试困难，且难以被自动化工具识别。
正确做法是并列使用：
-
class="button button--primary button--disabled"—— 两个修饰符互不干扰 - 避免
button--primary__icon--hidden：这是元素+修饰符嵌套，应拆成button__icon button__icon--hidden - 若需组合逻辑（如“主按钮且加载中”），仍保持分离：JS 控制添加/移除
button--primary和button--loading，而不是生成新组合类
容易被忽略的边界情况：动态类名拼接
服务端渲染或 JS 模板中拼接类名时，最容易漏掉主体。比如：
const modifier = isDisabled ? '--disabled' : '';
return `button${modifier}`; // ❌ 错误：可能输出 "button--disabled"，但缺少 block 主体
应始终保证主体存在：
const base = 'button';
const modifiers = [isPrimary && 'button--primary', isDisabled && 'button--disabled'].filter(Boolean);
return [base, ...modifiers].join(' '); // ✅ 正确：永远有 'button'
更稳妥的做法是封装工具函数，强制校验修饰符是否绑定有效主体，否则抛警告——这在大型项目里能提前暴露 80% 的 BEM 使用错误。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
