BEM本身不降低维护成本，反而初期增加输入负担；真正起效的是“块名唯一+元素单层+修饰符语义化”三条硬约束及工具链自动拦截。
直接说结论：BEM 本身不降低维护成本，反而在初期增加输入负担；真正起作用的是「块名唯一 + 元素单层 + 修饰符语义化」这三条硬约束，配合工具链自动拦截违规写法。
为什么改用 BEM 后 CSS 文件更难定位了
常见错误现象：搜索 button__text 找不到定义，或 DevTools 里看到 _button__text_kj23a 完全无法对应源码。
- CSS Modules 编译后会哈希类名，但 BEM 类名必须保留在源码中——它不是给浏览器看的，是给人和工具链读的
- 文件命名必须和 Block 名一致：比如
button.module.css里只允许出现.button、.button__icon、.button--primary - 禁止在同一个 CSS 文件里混入其他 Block 的样式，哪怕只是临时加个
.card__title也不行
哪些地方最容易写错下划线导致工具链失效
__ 和 -- 是正则解析的唯一锚点，错一个字符就彻底“失联”。
-
user_name会被误判为 blockuser+ elementname，但实际name并非该 block 的合法元素 -
form-input看似简洁，实则是独立 block 名，postcss-bem-linter直接跳过校验，后续加--disabled也无效 - VS Code 的 Auto Rename Tag 插件只监听
__/--模式，改header__logo不会同步更新header-logo
修饰符到底该挂在哪一级上
修饰符必须绑定到**实际发生状态变化的视觉单元**，不能靠父级降权控制子元素。
立即学习“前端免费学习笔记（深入）”；
- 正确：
card__title--disabled（仅标题变灰）、card--featured（整张卡片提升 z-index） - 错误：
card--disabled .card__title（破坏样式隔离，后续单独启用card__title需额外覆盖） - 禁止堆砌：
button--primary--large--loading是信号：这个组件职责过重，该拆了
老项目怎么避免新旧类名混用变成“双轨制”
最卡的不是技术，是协作断层：开发者看到 .user-list .item 和 .user-list__item 同时存在，根本不敢删任何一个。
- 策略核心：停止新增非 BEM 类名。新功能、修改过的组件、新增的 CSS 文件，必须用 BEM
- 用
stylelint-selector-bem-pattern开 strict 模式，保存即报错：Unexpected selector ".user-card h3" - 全局工具类（如
.sr-only）豁免 BEM，但必须归档到base/目录并加注释说明用途
真正容易被忽略的是：BEM 的价值不在类名长度，而在「文件名、目录结构、类名」三者之间的一致映射。一旦 components/Button/Button.module.css 里出现 .input 或 .modal__header，整个约束就从工程规范退化成了装饰习惯。
