BEM + Sass 解决结构漂移问题：class 名如 header__logo 表达语义归属而非 DOM 嵌套，Sass 嵌套仅提升书写效率，编译后仍为扁平 class，避免后代选择器脆弱性，且需统一 modifier 语义与命名边界。
在现代组件化开发中，直接使用类似 .header .logo 这样的后代选择器来编写样式，已经不仅仅是“写法不够优雅”的问题了，它本质上是一种不可靠的策略。原因很简单：DOM 结构一旦调整，样式关联瞬间断裂；当子组件需要被复用到不同上下文中时，类名冲突和样式覆盖就成了家常便饭。
为什么 BEM + Sass 嵌套不是炫技，而是解决结构漂移问题
BEM 方法论的核心在于，header__logo 这个类名并不描述视觉上的嵌套关系，它只声明一种语义上的归属。举个例子，即便 Logo 组件通过 Portal 被挂载到了 的末端，只要它在逻辑上隶属于 Header 模块，它就应当使用这个类名。而 Sass 中的 @include b('header') 这类混合宏，其角色仅仅是辅助生成扁平类名的工具，它既不改变样式对 DOM 结构的依赖，也不会引入任何额外的运行时开销。
- 真正起作用的，是类名本身，而非 Sass 的编译过程。
@include e('logo')最终输出的依然是header__logo，和手动书写并无二致。 - Sass 的嵌套语法（例如
.header { &__logo { ... } }）主要提供了书写上的便利，编译后生成的仍然是独立的 CSS 规则，绝不会产出像.header .logo这样脆弱的后代选择器。 - 如果团队已经在使用 PostCSS 插件（比如
postcss-bem），那么 Sass 并非强制选项。但不可否认，Sass 在开发者体验上通常更友好，尤其是在需要根据条件动态拼接修饰符（modifier）时，例如生成header--dark__logo这样的类名。
在 React/Vue 中传 class 名，谁该负责拼接 block 前缀
这里有一个常见的误区：让子组件内部硬编码 const className = 'header__logo'，或者去拼接 ${props.blockName}__logo。这种做法的问题在于，一旦父组件的块（block）名称需要更改，所有相关的子组件都必须同步修改，耦合度急剧上升。
- 推荐方式：由父组件统一决定块的上下文，并通过明确的 props（例如
iconClassName="header__logo"）将完整的类名传递给子组件。 - 次选方式：子组件通过
className属性接收父组件传递的块名（如header），子组件只负责添加自己的元素（element）后缀，如__logo。但这种方式必须严格约定：父组件传递的必须是纯粹的块名，而不能是带有修饰符的全名（例如，不能传递header--fixed）。 - 应当避免：使用 Context 或全局配置来自动注入块名。这虽然看似方便，却会让子组件的行为变得隐晦，极大地增加调试的复杂度。
Sass 中用 @include b() 时容易漏掉的关键点
很多项目虽然配置了 sass-bem 或自定义的 mixin，但往往没有意识到，这些工具主要解决的是“如何书写”的问题，而“如何管理”的规则仍需人为制定和维护。
立即学习“前端免费学习笔记（深入）”；
- 必须禁用嵌套中意外生成的后代选择器：例如，
.header { .logo { ... } }这种写法会被编译为.header .logo，这完全违背了 BEM 的扁平化原则。 - 统一修饰符（modifier）的语义与写法：
header--large是一个合法的修饰符，但header__logo--large和header--large__logo的语义截然不同。前者表示 logo 元素自身尺寸变大，后者则表示当整个 header 处于 large 状态时，其内部 logo 的样式。团队必须提前约定并在文档中明确这些差异。 - 合理组织文件结构：不必为每一个元素（element）都创建独立的文件（比如
_logo.scss）。在 BEM 中，块（block）是最小的可复用单元，因此header.scss文件理应包含所有header__*相关的样式规则。
实际上，最容易被忽略的一点是命名边界的模糊性。例如，在 header__na v 内部，又写了一个 na v__item，这就在不知不觉中引入了第二层 BEM 结构。正确的做法应该是统一命名为 header__na v-item。请记住，BEM 不是递归的，它的层级感仅仅体现在类名的字符串中，而不是在 DOM 结构或 Sass 的文件组织里。
