bem通过block-element-modifier三重锚定解决css协作失控问题：.logo类名因无上下文、所有权和状态标识导致样式污染，而.header__logo等命名天然隔离模块与状态，微前端和ssr场景下更依赖其预定义契约保障样式可靠性。
大型互联网公司不是“偏好”BEM，而是当项目规模突破百人协作、千组件复用、多端同构时，BEM的约束力能直接压住CSS失控的临界点。
为什么.logo类名在协作中必然出问题
常见错误现象：div.logo被全局重置样式覆盖；某人加了.logo img { width: 100% }，结果首页和弹窗里的 logo 全变形；审查元素发现样式来自reset.css、header.scss、modal.scss三个地方。
根本原因：类名无上下文、无所有权、无状态标识。它不回答三个关键问题——这个 logo 属于哪个功能模块？是哪个组件的一部分？当前是什么状态（比如暗色模式、加载中）？
-
.header__logo和.article__logo天然隔离，哪怕共用同一份 HTML 标签结构 - 禁止
.header .logo这类嵌套选择器，避免因 DOM 结构微调导致样式失效 - 所有类名必须业务语义化，禁用
wrap、container、box等泛词——因为它们无法回答“这是谁的 wrap？”
为什么button--primary--large--disabled是BEM失控信号
修饰符叠加是BEM最常被误用的点——它违背了“单一职责+可预测组合”的设计初衷，本质是把BEM当成了样式开关集合。
- 错误写法：
button--primary--large--disabled无法被button--large复用，也无法被主题系统按状态粒度接管 - 正确做法：用布尔组合代替连缀，如
button--primary button--large button--disabled，每个修饰符独立生效、可被单独覆盖 - CI 阶段必须用
stylelint-selector-bem-pattern拦截双连字符连用，否则后期重构成本指数级上升
为什么微前端和SSR场景下BEM几乎不可替代
微前端子应用或后端直出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结构被其他子应用意外修改，样式也不会失效
真正容易被忽略的是边界感
BEM只管有明确业务语义的组件，u-text-center 这类工具类、theme-dark 这类全局变量、reset-list 这类重置规则，它们本身就不属于某个 Block，强行塞进 BEM 结构反而别扭。
目录结构必须和 BEM 类名严格对齐：如果 card.css 文件里出现了 .user-profile__avatar，说明目录组织已失焦；card__button 却放在 /components/button/ 下，就破坏了“文件即模块”的契约。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
