.btn类名在百人团队中等于未定义，因其缺乏归属信息，无法明确所属模块、责任人及影响范围；而user-profile__submit-btn--disabled则自带上下文，清晰表达模块、元素与状态，实现语义化协作与精准定位。
为什么 .btn 这种类名在百人团队里等于没定义
因为纯类名不带归属信息，没人知道它属于哪个模块、谁负责维护、删掉会不会影响订单页。多个子应用（Billing、UserManagement）同时引入 .btn，又各自加 .btn { padding: 4px }，浏览器只认最后加载的那条——冲突不可预测，排查要翻 5 个文件。
真正可协作的类名必须自带上下文：user-profile__submit-btn--disabled 一眼可知：这是用户档案模块里的提交按钮，当前处于禁用态。不是靠文档约定，是靠名字本身说话。
SCSS 嵌套怎么不破坏 BEM 的作用域隔离
很多人写 .btn { &__icon { } &--loading { } } 就以为合规，但实际一不小心就漏出全局样式：
-
.btn { a { color: blue; } }编译后是全局a选择器，和 BEM 无关 -
.btn { & > span { } }生成.btn > span，依赖 DOM 结构，微前端里父容器一换就失效
必须守住两条线：
立即学习“前端免费学习笔记（深入）”；
- SCSS 中只允许
&__element和&--modifier两种嵌套形式 - 禁用所有带类型选择器（
& a）、关系选择器（& > div）、属性选择器（&[data-foo]）
构建时靠 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（连缀式，无法单独覆盖或复用）
CI 阶段必须配置 stylelint-selector-bem-pattern 拦截双连字符连用，否则后期重构成本指数级上升。
BEM 类名长度对性能的影响被严重高估，但维护成本真实存在
浏览器解析 product-card__price--highlighted 比 price 慢不了几个纳秒；真正拖垮交付节奏的是人脑匹配成本。
没有 BEM 时，查一个 margin-top 来源平均要打开 5 个文件；有 BEM 后，搜 card__price 就能定位到唯一 CSS 模块。
真正容易被忽略的是边界感：BEM 只管有明确业务语义的组件，u-text-center 这类工具类、theme-dark 这类全局变量、reset-list 这类归一化规则，硬塞进 BEM 结构只会让命名膨胀且语义失焦。
