BEM通过block__element--modifier三段式命名明确组件作用域与关系，避免样式冲突和结构依赖，提升可维护性。
为什么直接写 .header 或 .btn 容易引发样式冲突
多人协作时，.header 可能被首页、文章页、弹窗同时定义，彼此覆盖；.btn 在不同组件里加了 margin、padding、display，最终谁的生效取决于 CSS 加载顺序或选择器权重，而不是语义意图。BEM 不是为“看起来更专业”，而是把“这个按钮属于登录表单”这种业务关系，显式编码进类名里。
关键判断：如果你的 CSS 文件里出现过类似 .sidebar .item a:hover 这种依赖 DOM 结构的写法，说明你已经踩进可维护性陷阱了——结构一变，样式就断。
block__element--modifier 的三段式到底怎么拆
BEM 的三段不是命名游戏，每一段都绑定具体作用域和修改意图：
-
block是独立功能单元（如search-form、product-card），它不依赖外部上下文，能单独复用 -
element是 block 的组成部分（如search-form__input、product-card__price），必须依附于 block 存在，不能单独使用 -
modifier是状态或外观变体（如search-form__submit--disabled、product-card--featured），只改变已有表现，不新增结构
常见错误：product-card__price--sale 看似合理，但如果 “sale” 意味着价格旁要加 <span class="badge">SALE</span>，那就该拆成 product-card__badge 元素，而不是用 modifier 硬塞逻辑。
立即学习“前端免费学习笔记（深入）”；
如何让团队真正用起来，而不是写两行又切回老习惯
靠文档和口头提醒基本无效。需要从工具链上卡住出口：
- 在 ESLint + stylelint 中启用
selector-class-pattern规则，强制匹配^[a-z][a-zA-Z0-9]*(__[a-z][a-zA-Z0-9]*)?(--[a-z][a-zA-Z0-9]*)?$正则（注意：不接受大驼峰、下划线开头、数字开头） - VS Code 安装
BEM Tools插件，输入search-form后按 Tab 自动补全search-form__input和search-form--active - 禁止在 SCSS 中写嵌套超过 2 层的规则，例如
.search-form { &__input { ... } }可以，但&__input { &:hover { ... } }要拆成search-form__input:hover—— BEM 的类名已足够表达层级，嵌套只会模糊边界
真实代价：初期写类名会慢 2–3 秒，但一个月后，grep -r "card-title" 能准确定位所有标题样式，而不用翻 7 个文件猜哪个 .title 是卡片用的。
遇到第三方组件库（如 Ant Design）怎么兼容
别试图重写它的类名，BEM 是你 own code 的规范，不是全站 CSS 改造运动。正确做法是分层隔离：
- 第三方组件外层用 BEM 命名容器，例如
<div class="user-profile"><Avatar /></div>，再通过.user-profile .ant-avatar局部定制，但仅限尺寸/间距等视觉微调 - 如果要深度定制（如改
Antd Button的整个交互态），就封装一层user-profile__action-button，内部用asChild或透传 ref 接入，样式完全自治 - 警惕
!important泛滥——它通常暴露的是 BEM 边界没划清：本该用form-section__submit--loading的地方，写了.ant-btn.ant-btn-loading去强行覆盖
最常被忽略的一点：BEM 的 block 必须对应一个实际的 DOM 节点，而不是抽象概念。写 theme-dark 当作 block 是错的；应该用 app--dark，因为 <div class="app app--dark"> 才是真实存在的根容器。
