直接写.btn会破坏组件内聚性，因其无归属上下文，可能来自登录表单、弹窗footer或第三方库，导致全局样式竞争；BEM通过block__element--modifier将样式强绑定至功能单元，如.user-card__button仅属用户卡片，.modal-footer__button仅属弹窗底部，彼此隔离。
为什么直接写 .btn 会破坏组件内聚性
因为 .btn 没有归属上下文，它可能来自登录表单、弹窗 footer、甚至第三方 UI 库。一旦多个模块共用这个类名，样式就会在全局竞争——改一个地方，三处按钮同时变宽或错位。BEM 的 button 块不是为了“多写几个字符”，而是把“按钮”这个视觉单元和它的使用场景强绑定，比如 .user-card__button 只属于用户卡片，.modal-footer__button 只属于弹窗底部，彼此互不干扰。
__ 和 -- 不是装饰，是作用域锚点
双下划线 __ 表示“这个元素只在这个块里有意义”，比如 .search-form__input 和 .search-form__submit 必须和 .search-form 同时存在；双短横 -- 表示“这是当前块或元素的某种状态”，比如 .search-form--disabled 或 .search-form__submit--loading。它们共同构成一个不可拆分的语义单元：
-
.search-form__submit--loading✅ 合法：修饰符依附于元素，表达“提交按钮正处于加载中” -
.search-form--loading .search-form__submit❌ 危险：用后代选择器模拟 BEM，一旦 HTML 加了中间容器就失效 -
.search-form__submit--large❌ 越界：尺寸是整个表单的变体，应归为.search-form--large
嵌套层级失控时，不是加 __，而是拆出新 block
遇到类似 .card__header__title 这种写法，说明你正在强行维持一个过重的块。BEM 明确禁止元素嵌套元素。真实项目中更合理的做法是：
- 把
.card__header升级为独立块：.card-header - 它的内部结构由自己管理：
.card-header__title、.card-header__subtitle - 原
.card只负责布局容器和边界，不再承担标题样式逻辑
这样改完，改标题字体只需动 .card-header 相关规则，不会误触卡片边框、阴影或响应式断点。
立即学习“前端免费学习笔记（深入）”；
修饰符必须和基础类共存，否则样式链就断了
BEM 不是“开关式”命名，--disabled 不是独立样式开关，而是对已有块/元素的增强描述。常见错误是只写 CSS 规则 .button--disabled，却漏掉 .button 的基础定义。结果 HTML 里删掉 --disabled 类，整个按钮就没了边框、背景、圆角——因为没基础样式兜底。
正确姿势是：
- 每个
--modifier规则都基于基础类声明：.button--disabled { opacity: 0.5; cursor: not-allowed; } - HTML 中必须同时携带基础类：
class="button button--disabled" - 避免用
!important强行覆盖，那等于放弃 BEM 的可预测性
最易被忽略的一点：BEM 解决的是人理解成本，不是浏览器渲染问题。哪怕你用 CSS Modules 把类名哈希化了，user-profile__avatar--large 依然比 _a1b2c3 更容易被团队成员一眼看懂——这恰恰是协作中真正卡住重构进度的地方。
