BEM通过命名约束强制切断隐式依赖，实现样式天然隔离。所有类名扁平自解释，禁止嵌套选择器，Modifier只描述视觉/行为状态，配合工具链和团队共识保障隔离有效性。
为什么BEM能天然隔离样式作用域
BEM（Block-Element-Modifier）不是靠CSS新特性实现隔离，而是靠命名约束强制切断隐式依赖。只要严格遵循 block__element--modifier 格式，就无法写出 .header .nav li a 这类依赖嵌套结构的选择器——因为所有类名都是扁平、自解释、无层级假设的。
这意味着：
- 修改
button<strong>text</strong>样式，不会意外影响formlabel，哪怕它们在DOM里碰巧嵌套 - 删除某个组件HTML时，对应的所有类名（如
card<strong>image</strong>、cardfooter）都只出现在该组件内，全局搜索就能准确定位影响范围 - 测试只需关注单个
cardBlock 的视觉表现，不用考虑它被塞进sidebar还是modal后是否错位
不写嵌套选择器：BEM落地的第一道硬门槛
很多团队声称用了BEM，但实际代码里还藏着 .product-card .price 或 section h2。这类写法直接废掉BEM的隔离价值。
必须做到：
立即学习“前端免费学习笔记（深入）”；
- 所有样式规则都以一个BEM类名为根，例如
.product-card__title，而非.product-card .title - 组件内部元素必须显式声明类名，哪怕看起来“冗余”，比如
<div class="product-card__body"><h2 class="product-card__heading">...</h2></div>—— 不能省略product-card__heading - 遇到需要条件样式时，用Modifier代替状态推导：
.product-card--featured而非.featured .product-card
否则回归测试时，你永远不确定改了 .product-card 的 margin，会不会让某个没加BEM类的 h2 突然换行。
Modifier命名要反映视觉/行为变化，而非数据状态
--disabled 是合理Modifier，--is-loaded 就是危险信号。
原因在于：
-
--disabled直接对应UI反馈（置灰、不可点击），测试时可人工或截图比对 -
--is-loaded是数据状态，它本身不定义样式，容易导致开发时随意添加opacity: 1，后续别人加transition就可能让所有带--is-loaded的组件一起淡入——哪怕它们根本不需要动画
推荐做法：
- Modifier只描述「这个组件此刻长什么样」或「用户能怎么操作它」，例如
--small、--error、--with-icon - 数据状态交由JS控制类名增删，但类名本身必须是视觉导向的，比如加载完成 → 添加
--loaded，再由CSS定义.button--loaded { background: green; }
如何用工具守住BEM边界
光靠人工很难长期坚持。建议在工程中嵌入两层防护：
- ESLint +
stylelint-selector-bem-pattern插件，自动报错.header-nav a类选择器 - 组件快照测试（如Jest + RTL）中，断言渲染出的classList严格等于预期值，例如
expect(el).toHaveClass('search-form<strong>input--large')</strong>，而不是只检查是否存在search-forminput
最常被忽略的一点：BEM降低回归测试风险的前提，是团队所有人对「什么算一个Block」有共识。比如 user-avatar 和 user-badge 是否该合并为 user-summary Block？这种边界模糊处，不靠规范文档，而靠Code Review时当场问一句：“如果只改这个组件，哪些页面会动？”
