BEM类名过长本质是组件边界模糊、Modifier失控、状态表达错位，需通过拆分独立Block、提升状态至父级、用CSS变量替代样式值类名来根治，而非缩写或SCSS嵌套。
直接说结论：BEM类名过长不是靠命名空间缩写或SCSS混合宏“压”出来的，而是因为组件边界模糊、Modifier失控、状态表达错位——用namespace或@mixin硬压缩，只会让user-card__avatar--size-lg--theme-dark变成uc-avt--l-d，调试时完全无法对应源码。
为什么 SCSS 嵌套 + & 符号不能解决类名臃肿
SCSS 的 &__element 和 &--modifier 只是生成语法糖，不改变语义结构。它能帮你少打几个字符，但不会阻止你写出四层嵌套的类名。
- 常见错误现象：
.dashboard { &__user-card { &__header { &__title { ... } } } }→ 编译出dashboard__user-card__header__title，这已违反 BEM 原则（Element 不该跨 Block） - 真正问题不在写法，而在设计：这个 title 是 dashboard 的元素？user-card 的元素？还是独立的
headingblock？ - SCSS 嵌套深度建议 ≤ 3 层；超过后 CSS 选择器权重升高，覆盖成本变高，且 PurgeCSS 无法安全识别动态拼接类名
命名空间（namespace）在 CSS Modules 中的实际作用与陷阱
css-loader 的 localIdentName 支持 [path]_[name]__[local] 这类配置，但它只是给类名加前缀，并非语义压缩。
- 正确用法：
localIdentName=[name]__[local]--[hash:base64:5]→card__title--large_abc12，保留可读性的同时防冲突 - 危险操作：
localIdentName=[hash]或[folder]_[hash]→ 类名变成xyz7f，DevTools 里看不到原始语义，团队协作直接崩坏 - 命名空间 ≠ 缩写：你不能靠
namespace: 'uc'把user-card映射成uc后再写uc__avatar，这等于放弃 BEM 的自解释性
SCSS 混合宏（@mixin）适合封装什么，不适合封装什么
@mixin 是样式复用工具，不是类名生成器。它不该用来拼接 BEM 字符串，而应聚焦视觉逻辑收敛。
立即学习“前端免费学习笔记（深入）”；
- 适合封装：
@mixin button-variant($bg, $padding)，配合button--primary类名使用，把重复样式抽离 - 不适合封装：
@mixin bem-class($block, $elem, $mod)→ 最终还是得写#{bem-class('user', 'avatar', 'lg')}，既难 debug，又破坏构建时类名静态分析（PurgeCSS / Lightning CSS 会漏删） - 更稳妥的做法：用 JS 层条件组合类名，比如
[styles.card, isLarge && styles['card--large']].filter(Boolean).join(' ')，确保所有类名都来自styles对象，可被工具链追踪
最常被忽略的一点：类名长度问题，90% 出现在「页面容器」和「功能组件」混为一谈时。比如把整个 profile-page 当作 Block，然后往里塞 profile-page__user-card__avatar —— 其实 user-card 和 profile-page 是组合关系，不是隶属关系。拆开之后，HTML 更轻，CSS 更易维护，连事件委托都更干净。
