原生 CSS 嵌套（@nest）无法优雅替代 BEM，因其默认生成后代选择器，破坏 BEM 的扁平类名契约与作用域隔离；仅适用于伪类/伪元素等已定义类名的条件联动。
原生 CSS 嵌套语法（@nest）不能优雅重写 BEM，它和 BEM 的设计目标根本冲突——BEM 要的是扁平、可预测、工具链友好的类名契约；而原生嵌套默认生成后代选择器，天然破坏 BEM 的作用域隔离原则。
为什么 @nest 一用就错
原生嵌套不是“自动拼类名”，而是按 CSS 选择器规则组合。写 .card { .card__title { ... } }，浏览器实际解析为 .card .card__title（空格 = 后代），这直接违背 BEM 核心：所有样式必须绑定到具体类名，而非 DOM 层级。
- 调试时无法反推来源：DevTools 显示
.card .card__title，但你根本找不到这个选择器在源码里哪一行——它来自嵌套，不是手写的 - 构建工具（如 PurgeCSS）会误判：认为
.card__title是独立类，可能漏删或误删 - VS Code 插件失效：无法高亮跳转到
.card__title定义，因为源码里它没作为独立选择器出现 - 权重飙升：
.card .card__title比.card__title多一阶，后续覆盖成本翻倍
唯一能用 @nest 的合法场景：伪类/伪元素
BEM 允许对元素加伪态，但必须保持类名扁平。此时 @nest 可读性略好，且不破坏结构：
.button {
&__icon {
display: inline-block;
}
@nest &:hover {
&__icon {
transform: scale(1.1);
}
}
@nest &:disabled {
&__icon {
opacity: 0.5;
}
}
}
注意三点：
立即学习“前端免费学习笔记（深入）”；
- 必须用
@nest &:hover，不是&:hover（后者是草案未定行为，部分浏览器不支持） -
&__icon必须紧贴@nest块内，不能跨层，否则又变后代选择器 - 仍需手写
.button__icon类名——@nest不生成新类，只复用已有类名做条件匹配
想“少写类名”？危险操作清单
很多开发者试图用原生嵌套绕过 BEM 手动写类的步骤，结果全踩坑：
-
.card { &__header { &__title { ... } } }→ 编译出.card__header .card__header__title，三级嵌套，BEM 明令禁止 -
.card { &__content { @nest & > p { ... } } }→ 引入>子选择器，完全脱离 BEM 契约，工具链彻底失联 -
.card { @nest &[data-state="expanded"] { &__body { ... } } }→ 用属性代替 Modifier，但data-state不被 stylelint-selector-bem-pattern 识别，CI 直接放行违规
真正该做的：用原生嵌套补位，不是替代
BEM 的类名必须静态、显式、可 grep。原生嵌套只适合收口那些“必然伴随宿主出现”的状态逻辑，比如：
- 悬停时图标旋转：
@nest &:hover { &__icon { transform: rotate(90deg); } } - 焦点时边框变色：
@nest &:focus-within { &__input { outline: 2px solid var(--focus-color); } } - 响应式折叠：
@media (max-width: 768px) { @nest &--collapsed { &__content { display: none; } } }
重点在于：所有 &__xxx 都必须已在 HTML 中真实存在，且修饰符 &--xxx 已定义。原生嵌套只是让这些已存在的类名，在特定条件下联动生效——它不参与命名决策，也不缓解 BEM 的心智负担。
最容易被忽略的是：BEM 的约束力不在 CSS 写法，而在每次写 class="xxx" 时，你是否清楚这个 xxx 脱离当前组件文件，别人能否一眼看懂它属于谁、为什么存在。原生嵌套再炫，也替代不了这一问。
