BEM 是排错工具而非必经之路，它通过将归属编码进类名（如 .nav__btn）解决 CSS 全局冲突，约束 SCSS 嵌套形式，并降低人脑定位成本。

不是“必经之路”，而是当你第一次在协作项目里为一个 .btn 被意外覆盖而翻遍 7 个文件、查到 !important 来源时，BEM 就从命名规范变成了排错工具。

为什么 .btn 在多人项目里必然失控

CSS 没有作用域，.btn 是全局的。它可能来自 reset.css、header.scss、modal 组件、第三方 UI 库，甚至某人随手写的 div.btn。没人能单凭类名判断归属——它到底是导航按钮、表单提交按钮，还是轮播图控制按钮？BEM 把归属直接编码进名字：.nav__btn、.form__submit-btn、.carousel__control-btn，三者互不干扰，也不依赖 DOM 层级。

• 看到 .product-card__price--highlighted，立刻知道它只属于 product-card 模块，且处于高亮状态
• 搜索替换不会误伤其他模块的 price 类
• Code Review 时可直接判断：这个类是否该出现在当前 CSS 文件里

&__element 和 &--modifier 不是语法糖，是约束开关

SCSS 嵌套本身不等于 BEM 正确。很多人写：

.card {
  &__header { ... }
  & a { color: blue; } // ❌ 这条破坏了 BEM 防线
  & > .title { font-size: 1.2em; } // ❌ 同样越界
}

真正起作用的是构建时校验和编写规范：

PigX UI 前端开发

PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。

下载

立即学习“前端免费学习笔记（深入）”；

• 只允许 &__element 和 &--modifier 两种嵌套形式
• 禁用 & div、& a、& > span 等无语义选择器
• 用 stylelint-selector-bem-pattern 在 CI 阶段报错，而不是靠人眼检查

类名长度不是性能瓶颈，但人脑匹配成本真实存在

浏览器解析 .user-profile__avatar--xs 和 .avatar 的耗时差异可以忽略；真正拖慢交付节奏的是人脑定位成本：

• 没有 BEM 时，查一个 margin-top 来源平均要打开 5 个文件
• 有 BEM 后，搜 user-profile__avatar 就能定位到唯一 CSS 模块
• VS Code 插件 BEM Tools 输入 user-profile__ 回车即出所有元素候选，消除“想不出好名”的卡点

真正难的不是写出 block__element--modifier，而是让团队在加一个 tooltip 时，本能地新建 /components/tooltip/ 目录，而不是往 modal.css 里塞 .modal__tooltip——这需要目录结构契约、CI 检查、以及最初几个模块的示范性实现。