BEM 类名过长源于语义失控，如将页面级主题、跨场景尺寸等外部配置硬塞进 Modifier；应改用 CSS 自定义属性控制可变样式，并严格遵循 BEM 结构规范。
为什么 BEM 类名越写越长，反而更难维护
因为 BEM 的 block__element--modifier 套路在嵌套深、状态多时会指数级膨胀，比如 user-profile__avatar--size-large--is-loading--theme-dark。这不是字符数问题，是语义失控信号：一个 avatar 元素不该承载页面级主题（--theme-dark）或跨场景尺寸（--size-large）。这类 Modifier 实际上是外部配置，硬塞进类名会导致：
• 每次新增主题都要加新类，CSS 文件线性膨胀
• purgecss 无法识别动态拼接的类名，误删风险高
• DevTools 里搜 avatar 找不到 user-profile__avatar--size-large--theme-dark，调试断链
• 复制粘贴 HTML 时，--theme-dark 在新页面里毫无意义
用 CSS 自定义属性替代冗余 Modifier 类名
当 Modifier 只控制颜色、间距、圆角等可变量时，类名应回归语义，把值交给 CSS 变量驱动：
• 变量定义在 :root 或 Block 根元素（如 .user-profile），不写死在每个 Modifier 类里
• JS 动态注入变量更可控：el.style.setProperty('--avatar-size', 'large')
• 避免在 :root 下塞业务变量，比如 --user-avatar-border-radius 应该放在 .user-profile 块内
• 示例：
:root {<br> --color-primary: #007bff;<br> --button-padding: 12px 24px;<br>}<br>.user-profile__avatar {<br> background-color: var(--color-primary);<br> padding: var(--button-padding);<br>}
别让 SCSS 嵌套破坏 BEM 结构
&__title { } 看着省事，但一旦混进条件逻辑（比如 &.is-open { &__title { } }），就可能产出 .card.is-open__title 这种非法选择器——浏览器能解析，但人脑无法映射回 BEM 意图：
• SCSS 中只允许一层 &__xxx 或 &--xxx，且必须直接挂载在 Block 根选择器下
• 状态控制交给 JS：用 card--expanded 而非 .card.is-expanded
• 禁用 stylelint-selector-bem-pattern 的 ignore 选项，让它在 CI 阶段报错 .card__header--active 这类合法但易歧义的写法
真正该用 BEM 的场景和边界在哪
BEM 不是万能胶，也不是越小越好：
• ✅ 适合组件库、微前端子应用、多人协作的中后台系统（尤其含大量表单/卡片/列表）
• ❌ 别强行 BEM 的地方：纯静态页、单页营销页、CSS-in-JS 主导的项目（此时 BEM 语义可转为 JS 变量名）
• 注意 block 边界：一个 block 应有明确职责和独立 DOM 结构，比如 search-bar 是 block，但 search-bar__input 不能跨出它的根元素范围
• 最常被忽略的一点：BEM 的「块」不是越小越好，而是要语义完整、职责单一、DOM 自包含；.button 是块，.button__icon 是元素，.button--primary 是修饰符——但 .button--blue 就不该存在，颜色应由设计系统变量统一控制
立即学习“前端免费学习笔记（深入）”；
