BEM通过block__element--modifier结构将归属、角色、状态三重语义硬编码进类名，使类名自解释、可搜索、天然隔离，杜绝开源项目中因无上下文导致的样式覆盖与误用。
因为BEM把“谁的样式、作用在哪、当前什么状态”三个问题直接塞进类名里，开源项目没人给你讲上下文，靠名字自己说话。
为什么开源项目依赖类名自解释性
没人会为你写文档说明.card__title属于哪个模块、能不能单独复用。BEM强制块前缀（如user-card__title）就是所有权声明——搜user-card就能定位全部模板、样式、JS逻辑。而.title或.card-title在大型开源库中等于裸奔，极易被其他子模块覆盖或误用。
- GitHub 代码搜索时，
grep -r "product-card__" .能瞬间锁定整个组件边界 - PR Review 时，看到
checkout-form__submit-btn--disabled就明白这是结账表单专用按钮的禁用态，不是通用工具类 - 第三方开发者 fork 后改样式，不会意外影响
search-form__submit-btn——块名天然隔离
为什么BEM能降低CSS-in-JS以外的协作门槛
开源项目常需兼容 SSR、微前端、后端模板直出等无 JS 运行时场景。modal__close--hovered这种类名，PHP 工程师能看懂、审计能追溯、CDN 缓存可命中；而tw-6 tw-h-6或css-1a2b3c对非前端协作者毫无意义。
- 禁止嵌套选择器（如
.modal .close）→ DOM 结构变动不破样式，SSR 和客户端 hydration 一致性更高 - 所有规则必须单类名触发 → 构建产物里不会出现空格选择器，
grep -r "\.[a-z]\+ \.[a-z]" dist/扫一遍就能确认是否合规 - 修饰符用
--而非-或_→stylelint-selector-bem-pattern能自动识别并报错，CI 拦截拼写错误（如button_primary）
为什么开源维护者最怕“伪BEM”和修饰符滥用
真正让开源项目失控的，不是没用BEM，而是用了但没守底线：比如HTML写了class="card card--featured"，CSS却只定义了.card--featured，删掉修饰符整个组件就崩；又或者写出button--width-200px，换单位就得新增button--width-20rem，版本迭代时类名爆炸。
立即学习“前端免费学习笔记（深入）”；
- 伪BEM：漏基础块样式，下游使用者一升级就视觉断裂
- 跨 Block 元素：
card__header__title违反 BEM 层级规则，工具链无法校验，IDE 跳转失效 - 修饰符含具体值：
--small、--red、--2x这类命名在响应式或主题切换时必然卡死
真正难的不是记住__和--怎么写，而是每次敲下这两个符号时，都得确认：这个元素真是它所属 Block 的固有部分？这个修饰符描述的是稳定可枚举的状态，还是临时视觉补丁？
