BEM是CSS框架解决样式失控的最小可行结构，它将归属（block）、层级（element）、状态（modifier）直接编码进类名，确保跨项目、多技术栈复用时样式隔离、可维护、不冲突。
因为BEM不是“可选风格”，而是解决样式失控的最小可行结构——框架要被多人、多项目、跨技术栈复用，就必须把归属、层级、状态这三个变量直接编码进类名里，否则一接入就崩。
为什么CSS框架必须显式声明“这个样式属于谁”
BEM的block名（如btn、modal）本质是组件契约的文本化表达。框架不靠注释或文档约定作用域，而是让btn__icon和form__icon天然隔离——哪怕DOM结构完全一样，样式也不会互相污染。
常见错误现象：.icon这种泛化类名一旦被框架导出，就会立刻和宿主项目里的.icon冲突；而btn__icon自带命名空间，npm install后开箱即用。
- 框架作者无法控制宿主项目的CSS加载顺序，所以不能依赖层叠权重兜底，只能靠类名唯一性
- 微前端场景下，子应用JS未执行时，HTML已由后端直出，
btn--loading这种类名就是唯一可信赖的样式锚点 - Vue/React组件库中，
card__header能直接映射到<CardHeader>组件，新人看类名就能反推文件路径
为什么框架级响应式必须绑定到BEM类，而不是媒体查询分散写
框架要支持主题切换、断点覆盖、SSR兼容，就不能让@media规则散落在几十个文件里。BEM强制把响应式逻辑收束到单个类上，比如card--stacked表示整块结构切换，btn__label--truncated只影响元素自身。
立即学习“前端免费学习笔记（深入）”；
常见错误现象：框架里写.card .price { font-size: 12px; }配@media，结果宿主项目改了.card的DOM结构（比如加了wrapper），样式立刻失效；而card__price--sm只要类名存在，样式就生效。
- 构建产物里所有
@media必须只包含一个BEM类选择器，禁止空格，否则无法被stylelint-selector-bem-pattern校验 - 框架的
button--primary和button--outline必须是互斥状态，不能靠!important或权重堆砌来覆盖 - SSR直出页面时，
search-form--mobile这类类名能让后端模板工程师直接理解语义，无需查JS源码
为什么框架开发者最怕“伪BEM”和修饰符滥用
框架一旦放行btn--width-200px或modal--left这类含具体值或位置的修饰符，就等于放弃状态抽象能力——宿主项目换单位、加断点、做RTL适配时，就得新增一堆类，框架维护成本指数级上升。
更致命的是“伪BEM”：class="btn btn--primary"但CSS只写了.btn--primary，漏掉基础.btn样式，框架一升级，所有宿主页面按钮直接失形。
- 框架的
block名必须业务语义化：date-picker✅，box❌；search-form✅，form❌ - Element禁止跨Block使用：
btn__icon不能塞进nav容器里，否则破坏归属契约 - 修饰符必须可枚举、可组合：
btn--disabled✅，btn--large✅，但btn--disabled--large要谨慎——它暗示两个状态强耦合，不利于主题系统按粒度接管
真正难的不是写出user-card__avatar--xs，而是每次敲下__和--时都得确认：这个元素是否真属于该Block？这个修饰符是否稳定、可复用、不带硬编码值？框架的生存底线，就卡在这两个字符的判断上。
