BEM本身不提升鲁棒性，但强制你做三件事——隔离作用域、显式声明依赖、拒绝隐式状态——这三点才是应对业务变更的真正防线。
直接说结论：BEM本身不提升鲁棒性，但强制你做三件事——隔离作用域、显式声明依赖、拒绝隐式状态——这三点才是应对业务变更的真正防线。
为什么BEM能减少“改一个样式崩三个页面”的事故
业务变更是常态：按钮从单色变成渐变、侧边栏从固定宽度变成可折叠、表单字段突然要加校验图标。传统CSS靠层级选择器（如 .sidebar .menu li a）或泛用类名（如 .active），一旦DOM结构调整或组件复用场景变化，样式就大概率失效或误生效。
BEM通过命名强制约束作用域边界：
-
.article__heading只属于.article这个块，不会意外影响.sidebar__heading -
.button--disabled明确表示这是.button的一种状态变体，而不是全局的“禁用态” - 没有父选择器、没有标签选择器、不依赖DOM深度，组件挪位置、嵌套层级变深变浅，样式照常工作
SCSS中用@mixin和@function封装BEM逻辑时的坑
很多人用SCSS写BEM，结果写出一堆难以维护的嵌套：
.button {
&__icon {
&--left { margin-right: 8px; }
&--right { margin-left: 8px; }
}
&--primary {
background: $blue;
&__icon { color: white; }
}
}
问题在于：&__icon 在 &--primary 下又被重定义，导致语义混乱（是“主按钮里的图标”，还是“图标在主按钮里”？）。更糟的是，这种写法让 .button__icon 的样式实际依赖于父级状态，破坏了BEM“元素应独立于修饰符”的原则。
正确做法是把修饰符逻辑收口到块级：
- 用
@mixin button-icon($position)统一生成.button__icon--left类，不嵌套 - 用
@function bem($block, $element: null, $modifier: null)动态拼类名，避免手写错误 - 禁止在
&--xxx里再写&__yyy—— 修饰符只改变块或元素自身，不创造新结构
当产品要求“这个按钮在弹窗里要变小”时，该加--in-modal还是改.button--small
这是BEM落地中最常被问错的问题。关键不是“怎么命名”，而是“谁该为这个变化负责”。
如果只是弹窗内所有按钮统一缩小，那属于布局上下文变化，不应污染按钮本身的语义 —— 此时应该用容器修饰符：.modal__content .button--small，或者更干净地：.modal--compact .button（即由弹窗块来声明其内部按钮的尺寸策略）。
只有当“小号按钮”成为一种独立可复用的变体（比如在表格操作列、卡片底部都需一致的小按钮），才该定义 .button--small。否则，硬加 --in-modal 会制造大量场景专属修饰符，最终类名爆炸，失去BEM本意。
判断标准就一条：这个样式变体是否脱离当前上下文后仍有意义？
Vue单文件组件中，scoped和BEM要不要共存
要，但必须分清职责：scoped 解决的是CSS注入时的全局污染，BEM解决的是语义组织与协作约定。
常见错误是以为加了 scoped 就可以随便起名，结果写出 .title、.content 这类弱语义类名。一旦组件被复用到另一个同名块里（比如两个 Card 组件），scoped 确保样式不冲突，但开发者读代码时完全无法判断哪个 .title 对应哪部分结构。
推荐组合方式：
- 模板中仍严格使用BEM命名：
- 样式块保留
scoped，但写法是.card__title { ... }，而非.card :deep(.title) - 需要穿透样式时（如第三方组件定制），用
:deep(.el-button--primary)，而不是放弃BEM去套用.card .el-button
真正容易被忽略的点是：BEM的鲁棒性不来自语法，而来自团队对“块边界”的共识。一个按钮是不是独立块？一个带搜索的下拉框，搜索框是它的元素，还是另一个块？这类判断比写对双下划线更重要——它决定了样式将来能不能被安全抽取、复用、替换。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
