& 是 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 结构和样式职责边界的理解是否清晰。