bem是设计系统css层落地的前提，因纯类名如.btn无归属信息易导致样式冲突，而bem通过btn__label、btn--size-large等命名将组件归属、状态与上下文直接写入类名，形成可预测、可隔离的接口契约。
BEM 不是“适合”设计系统，而是设计系统能跑起来的前提——没有 BEM，所谓“可复用组件”在 CSS 层面就是空中楼阁。
为什么 .btn 在设计系统里等于没定义
设计系统要求一个 button 组件的样式行为可预测、可隔离、可被安全引用。但纯类名如 .btn 或 .primary 没有归属信息：它属于哪个业务模块？是否被其他团队覆盖？删掉会不会影响订单页？
一旦多个子应用（Billing、UserManagement、Analytics）都引入同一份按钮样式，又各自加了 .btn { padding: 4px }，浏览器只认最后加载的那条，没人能说清谁赢谁输。
BEM 把归属直接写进名字：btn__label、btn--size-large、checkout-form__submit-btn--disabled——类名本身就成了接口契约，使用者不用翻文档就知道这是谁家的按钮、什么状态、在哪上下文生效。
SCSS 嵌套怎么不破坏 BEM 的作用域隔离
很多人以为写了 .btn { &__icon { } &--loading { } } 就算遵守 BEM，但实际一不小心就漏出全局样式：
常见错误：.btn { a { color: blue; } } 编译后是 a 全局选择器，和 BEM 无关；
更隐蔽的是：.btn { & > span { } } 生成 .btn > span，依赖 DOM 结构，微前端里父容器一换就失效。
必须守住两条线：
- SCSS 中只允许
&__element和&--modifier两种嵌套形式 - 禁用所有带类型选择器（
& a）、关系选择器（& > div）、属性选择器（&[data-foo]）
postcss-bem-linter 或 stylelint-selector-bem-pattern 拦截，而不是靠人眼。
修饰符（Modifier）怎么避免变成样式开关集合
设计系统里最常崩在修饰符滥用：btn--width-200px、card--border-radius-8 这类写法把具体值塞进类名，导致响应式、主题切换、token 替换全失效。
真正可维护的修饰符必须语义化、可组合、可接管：
- ✅
btn--primary（代表“主操作”，由设计令牌--color-brand-primary驱动） - ✅
btn--loading（代表状态，可与--primary同时存在） - ❌
btn--bg-blue-500（视觉值，主题换色时得全量替换） - ❌
btn--primary--large--disabled（连缀式，无法单独覆盖或复用）
stylelint-selector-bem-pattern 拦截双连字符（-- 后不能再跟 --），否则后期重构成本指数级上升。
BEM 类名和设计令牌（Design Tokens）怎么解耦
很多团队把 --btn-bg-color、--card-padding-sm 直接塞进组件 CSS 里，结果换主题时要改几十个文件。
正确解耦方式：
- 所有变量定义在顶层
:root或主题类（.theme-dark）中，如--color-surface: #fff - BEM 类里只做映射：
.card { background-color: var(--color-surface); } - 禁止在
.card__header里声明--card-header-padding这种组件专属变量 - 原子类（如
u-p-4）也必须引用统一 token：padding: var(--spacing-lg)，而非手写16px
真正难的不是拼出 user-profile__avatar--xs，而是让团队在加新组件时，本能地新建 /components/avatar/ 而不是往 modal.css 里塞 .modal__avatar——这需要目录结构契约、CI 校验、以及最初几个模块的示范性实现。BEM 的约束力不在命名规则里，而在整个工程链路是否把它当真。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
