SASS嵌套与BEM结合易导致维护困难，因深层嵌套生成冗余选择器、增加权重、破坏BEM解耦初衷；应限制嵌套范围、独立声明BEM类名、合理使用变量与mixin、采用@use/@forward模块化，并在跨组件、伪类、媒体查询等场景放弃嵌套。
为什么SASS嵌套+ BEM容易写出难以维护的CSS
因为嵌套层级一深，.block__element 就会变成 .block .block__element .block__element--modifier 这种冗余选择器，既增加权重、又放大耦合——BEM本意是解耦，嵌套反而把它锁死了。
常见错误现象：Inspect Element 里看到选择器长度爆炸，改一个$color-primary却要翻三层@mixin和五层嵌套；或者加个:hover状态时，发现父级&__item已经用&绑死了上下文，根本没法复用。
- 只在语义明确的父子关系中嵌套，比如
&__header和&__header-title可以，但&__header &__footer绝对不行 - BEM类名必须独立声明，禁止用
&拼接：写.card__body，别写&__body套在.card下面 - 所有修饰符（
--hover、--disabled）统一用&.block--modifier写法，不嵌套进元素内部
SASS变量和@mixin怎么配合BEM避免重复
变量不是用来存颜色值就完事的；@mixin 也不是为了“看起来高级”。它们真正的协作点在于：把BEM中高频变化的部分抽出来，让类名保持静态，行为靠参数驱动。
使用场景：按钮组件有 primary/secondary/small 多种组合，但 HTML 里只写 <button class="btn btn--primary btn--small">，不希望每个变体都手写一遍样式。
立即学习“前端免费学习笔记（深入）”；
- 定义基础变量时按BEM维度分组：
$btn-padding、$btn--primary-bg、$btn--small-font-size -
@mixin btn-variant($bg, $color)接收具体值，而不是写@mixin btn-primary()这种死绑定 - 用
@include btn-variant($btn--primary-bg, $btn--primary-color)调用，确保样式逻辑可组合、可覆盖
如何用@forward和@use拆分BEM模块而不破坏作用域
很多人用 @import 把所有_buttons.scss、_forms.scss塞进一个入口，结果$z-index-modal被_dropdown.scss意外覆盖——@use才是BEM模块化的安全阀。
性能影响：每个@use都会生成独立命名空间，不会污染全局，但编译后CSS体积几乎不变；兼容性上，Node Sass已停止维护，必须用 Dart Sass（v1.23+）才支持。
- 每个BEM块单独建文件夹：
components/card/_index.scss作为入口，只@forward "card"; @forward "card__header"; - 在主文件用
@use "components/card" as card;，调用时显式写card.$card-spacing，一眼看出来源 - 禁止在
_index.scss里写实际样式，只做@forward和@use，否则模块边界就模糊了
哪些BEM场景下应该放弃SASS嵌套
嵌套不是银弹。当出现跨组件交互、伪类组合、媒体查询响应或第三方库覆盖时，硬套嵌套只会让调试成本翻倍。
典型错误：写 .modal &__content { @media (max-width: 768px) { ... } }，结果@media被包进.modal__content作用域，无法匹配真实DOM结构；或者想给 input[type="text"].form__field:focus 加样式，却发现&:focus被锁在.form__field嵌套里出不来。
- 所有带
[attr]、:not()、:has()的选择器，一律平级书写，不嵌套 - 媒体查询统一提到最外层，用
@media screen and (min-width: 769px) { .block__element { ... } } - 第三方组件（如
react-select）的class，用html .rs__control这种强限定写法，别试图用&去套它
真正难的不是写对语法，而是每次敲下 & 前，得想清楚这个“父上下文”是不是业务上真的不可剥离——BEM的类名是契约，SASS嵌套是实现，别把实现当成契约本身。
