BEM通过强制命名边界和切断隐式依赖阻断连锁反应。它要求样式锚定单类名（如header__nav-link），不依赖DOM层级；block物理隔离确保元素归属明确；工具链依赖可预测字符串模式，但需静态类名与团队边界意识协同生效。
BEM 本身不抑制熵增，它靠强制命名边界和切断隐式依赖，把样式失控的“概率”压到最低——项目越大，越容易踩中那些没人意识到的耦合点。
为什么BEM能阻断“改一处、崩一片”的连锁反应
传统写法里，.header .nav a 这类选择器把样式逻辑绑在 DOM 层级结构上。一旦某人重构了导航结构，或在另一个模块里复用了 .nav 类，就可能意外激活这组规则。BEM 要求所有样式必须锚定在单个 class 上，比如 header__nav-link，它不关心父容器是不是 header，也不依赖兄弟节点是否存在。
- 改
header的 display 不会影响header__nav-link的布局行为 - 删掉整个
header组件，对应 CSS 可安全移除，不会残留“幽灵规则” - 新人加新卡片组件时，只要命名合规（如
dashboard-card__title），就不会和旧的user-card__title冲突
BEM 的命名不是为了好看，而是给构建工具“可预测的字符串模式”
像 PurgeCSS 这类工具只认字符串，不理解语义。BEM 提供的 block__elem--mod 模式让工具敢删、能删准。但前提是类名必须静态、可扫描。
- 禁止写
class="button__icon--${size}"——PurgeCSS看不到运行时生成的button__icon--large - 第三方组件必须显式加 class：
<van-button class="van-button">，否则样式无法保留 - 用
clsx+ 常量拼接比模板字符串更安全：const BLOCK = 'search-bar'; clsx(`${BLOCK}__input`, mod && `${BLOCK}__input--${mod}`)
最容易被忽略的 BEM 生效前提：block 边界必须物理隔离
BEM 规则失效的高发场景，是 block 范围被跨出。比如定义了 search-bar block，却在它的 HTML 外部写了 search-bar__input ——这个类名再合规，也违背了 BEM 的契约本质。
立即学习“前端免费学习笔记（深入）”；
- 每个 block 必须有独立根元素，且所有
__子类只能出现在该根内 -
user-card__avatar不能塞进profile-section的 DOM 里，除非它本身就是profile-section的一部分 - 修饰符如
--disabled必须依附于 block 或 element，不能单独存在（disabled是状态，button--disabled才是语义）
真正让 BEM 在大型项目里不退化成一堆长类名的，不是命名规则本身，而是每次新增 class 时，团队是否真在问：“这个元素属于哪个 block？它的边界在哪？有没有被其他地方悄悄复用？”——这种判断没法自动化，但缺了它，BEM 就只是徒增字符的装饰。
