CSS利用Sass处理复杂选择器_通过&父选择器简化代码结构

& 是 Sass 中精确复用当前选择器上下文的语法糖，解决嵌套中选择器复用不准确的问题；它始终绑定直接外层选择器，支持伪类、属性选择器及 BEM 命名，但不可跨层或滥用。

什么是 & 父选择器，它到底解决什么问题

当你写 .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 往往由 JS 动态添加，和 .form__field 并非强耦合，强行嵌套反而增加维护成本。

• 跨组件复用的状态类（如 .is-hidden、.has-error）建议单独定义，不通过 & 派生
• 涉及第三方库类名时慎用：.react-select { &__control { … } } 可行，但若库升级改了内部结构，嵌套链就断了
• 当一行里出现超过两个 &（如 &.mod1.mod2:hover），可读性骤降，不如拆成独立规则

真正难的不是写出嵌套，而是判断哪些关系值得用 & 绑定——它暴露的是你对 DOM 结构和样式职责边界的理解是否清晰。