CSS如何使用Sass处理复杂选择器：通过&父选择器简化代码结构
什么是 & 父选择器，它到底解决什么问题
当你写下 .btn { &.disabled { opacity: 0.5; } } 时，那个 & 符号可不是什么简单的占位符。它的本质，是精确复用当前选择器上下文的语法糖。这意味着它不做字符串拼接，也不搞模糊匹配，而是把左侧完整的选择器，原封不动地“搬”到 & 所在的位置——这才是它和普通嵌套最根本的区别。
一个常见的误区，是把它当成“父级缩写”来用。比如在 .card { .header { &.active { … } } } 这段代码里，有人会误以为 & 指向的是 .card。但实际情况是，它牢牢绑定的是紧邻的上层选择器 .header。结果编译出来的是 .card .header.active，而不是很多人预期的 .card.active .header。这一点可得记牢了。
&永远只绑定到直接外层选择器，不会跨层级“向上追溯”。- 多个
&可以并存使用：像.link { &:hover, &:focus { color: blue; } }这样的写法是完全合法的。 - 它支持修饰符拼接：
.icon { &--large, &--small { display: inline-block; } }编译后就是清晰的.icon--large, .icon--small。
用 & 处理 BEM 类名组合时的关键细节
BEM 命名规范可以说是 & 最自然的用武之地。但这里有个细节容易踩坑：命名一致性带来的编译风险。举个例子，.menu { &__item { padding: 4px; &--highlighted { background: yellow; } } } 会正确输出 .menu__item--highlighted。但如果手一滑，写成了 .menu { &__item { &.highlighted { … } } }，结果就变成了 .menu__item.highlighted（两个类名并列）。这看似微小，实则破坏了 BEM 的语义隔离原则。
- 修饰符必须用
&--xxx或&.xxx来明确区分意图：前者生成一个全新的类名，后者则表示“元素同时拥有这两个类”。 - 当元素嵌套层级过深时，
&无法跳过中间层。比如.block { &__elem { &__subelem { … } } }就是非法的——Sass 不允许在&后面再接另一个&__。 - 这时候，推荐配合
@at-root规则提前跳出嵌套：.block { &__elem { @at-root #{&}--modifier { … } } }是个不错的解决方案。
当 & 遇到伪类、媒体查询和属性选择器
& 能够无缝接入各种复杂上下文，但必须明白，它的插入动作发生在选择器解析阶段，而非运行时。比如，.input { &[disabled] { background: #eee; } } 会编译为 .input[disabled]，这没问题。再看 .input { @media (max-width: 768px) { & { display: block; } } }，它会生成 @media (max-width: 768px) { .input { … } }。在这里，& 依然代表 .input，并没有被外层的媒体查询所“遮蔽”。
话说回来，有几个技术要点需要特别留意：
- 伪类必须紧跟
&：&:hover✅ 是对的，而& :hover❌（中间的空格会让它变成后代选择器）。 - 属性选择器内部，
&不能出现在中括号里：像&[data-id="&"]这样的写法是无效的，因为 Sass 不会解析引号内的&。 - 组合选择器是合法的：
& + &这样的写法会生成.sibling + .sibling，非常适合用来样式化相邻的兄弟元素。
哪些情况不该硬套 &，该直接写平铺选择器
过度依赖 & 会导致嵌套层级失真，尤其是在逻辑上本就不属于同一语义块的情况下。例如，表单的验证状态通常独立于组件结构。像 .form { &__field { &.is-error { … } } } 这种写法，看起来合理，但 .is-error 这类状态类往往由 Ja vaScript 动态添加，与 .form__field 并非强耦合。强行嵌套在一起，反而会增加后期的维护成本。
- 跨组件复用的状态类（比如
.is-hidden、.has-error），建议单独定义，不要通过&来派生。 - 涉及第三方库的类名时要慎用：
.react-select { &__control { … } }虽然可行，但如果第三方库升级后改变了内部结构，整个嵌套链就可能断裂。 - 警惕可读性陷阱：当一行代码里出现超过两个
&（例如&.mod1.mod2:hover），可读性会急剧下降。这种情况下，拆分成独立的规则往往是更好的选择。
说到底，真正的难点不在于写出复杂的嵌套，而在于判断哪些关系值得用 & 去绑定——这背后考验的，是你对 DOM 结构和样式职责边界的理解是否足够清晰。
