BEM是Yandex提出的CSS命名方法论，通过Block（块）、Element（元素）、Modifier（修饰符）三部分及__、--分隔符实现作用域隔离、从属锁定与状态语义化，专为百人协作、千组件复用、微前端与SSR等高复杂度场景提供不可绕过的样式契约。
大型互联网公司不是“偏好”BEM，而是当项目规模突破百人协作、千组件复用、多端同构时，BEM的约束力能直接压住CSS失控的临界点——它不靠工具链魔法，只靠命名不可绕过的三重锚定：block锁作用域、__element锁从属关系、--modifier锁状态语义。
为什么BEM在微前端和SSR场景下几乎不可替代
微前端子应用或后端直出HTML（如Java/PHP模板）时，无法依赖JS运行时动态拼类或CSS-in-JS哈希，样式必须靠预定义类名驱动。此时BEM类名就是契约本身。
-
user-profile__avatar--xs这种写法让后端模板工程师也能读懂含义，审计时可追溯到具体业务模块，而非w-6 h-6 rounded-full这类纯视觉描述 - SSR页面中多个子应用共用同一份CSS文件，
search-form__input和checkout-form__input天然隔离，不会因都叫input而互相覆盖 - 禁止使用嵌套选择器（如
.card .title），意味着即使DOM结构被其他子应用意外修改，样式也不会失效
当团队开始写button--primary--large--disabled时，说明BEM已失控
修饰符叠加是BEM最常被误用的点——它违背了“单一职责+可预测组合”的设计初衷，本质是把BEM当成了样式开关集合。
- 正确做法：用布尔组合代替连缀，如
button--primary button--large button--disabled，每个修饰符独立生效、可被单独覆盖 - 错误现象：
button--primary-large-disabled无法被button--large复用，也无法被主题系统按状态粒度接管 - CI阶段必须用
stylelint-selector-bem-pattern拦截双连字符连用，否则后期重构成本指数级上升
BEM类名长度对性能的影响被严重高估，但维护成本真实存在
浏览器解析product-card__price--highlighted比price慢不了几个纳秒，真正拖垮交付节奏的是人脑匹配成本。
立即学习“前端免费学习笔记（深入）”；
- 没有BEM时，查一个
margin-top来源平均要打开5个文件；有BEM后，搜card__price就能定位到唯一CSS模块 - VS Code插件
BEM Tools可自动补全__和--，输入card__回车即出所有元素候选，消除“想不出好名”的卡点 - 类名冗长的代价，远小于因命名模糊导致的样式覆盖bug——比如改
.header .logo结果把footer .logo也干掉了
真正容易被忽略的是边界感：BEM只管有明确业务语义的组件，u-text-center这类工具类、theme-dark这类全局变量、reset-list这类归一化规则，硬塞进BEM结构只会让命名膨胀且语义失焦。
