结论：Sass嵌套响应式导航应避免顶层无节制嵌套媒体查询，正确做法是抽离断点为@mixin或变量、组件级写媒体查询、语义化分层命名、分离移动端状态、分层管理变量、禁用@extend改用@mixin、写标准属性交由Autoprefixer处理。
怎么用Sass嵌套写响应式导航，又不掉进选择器爆炸的坑
直接说结论：别在顶层用 & 无节制嵌套媒体查询，否则编译出的选择器层级太深，CSS权重失控，后续覆盖反而更难。Sass嵌套真正该省的是重复的父选择器，不是把所有断点都塞进一个规则块里。
常见错误现象是写成这样：
.nav {
display: flex;
@media (max-width: 768px) {
flex-direction: column;
&__item { font-size: 14px; }
&__link { padding: 8px; }
}
}
结果编译出 .nav@media (max-width: 768px) .nav__item 这种非法语法，或者更糟——如果用了错误的嵌套方式，实际生成一堆高权重、难维护的选择器。
- 正确做法是把断点抽成
@mixin或变量，媒体查询写在组件级，而非嵌套在元素内部 - 导航结构建议按语义分层：用
.nav控制布局，.nav-list管流式容器，.nav-item和.nav-link各司其职，避免靠嵌套“猜”结构 - 移动端折叠逻辑（比如 hamburger）不要和基础样式耦合，单独抽成
.nav--mobile或用 JS 切换类名，Sass 只负责定义状态样式
Sass变量怎么管住导航字体、间距、断点这些易变参数
导航的字体大小、行高、内边距、断点阈值，全是高频修改项。硬编码在每个规则里，改一次要搜五处；全塞进一个 $config map 又太重。折中方案是分层变量：
立即学习“前端免费学习笔记（深入）”；
-
$nav-font-size-base、$nav-padding-inline这类基础值，直接赋值，不套函数 - 断点用
$breakpoint-mobile: 768px而不是map-get($breakpoints, mobile)，除非项目真有十几种设备类型 - 颜色慎用
darken()或lighten()动态算——它们在压缩后仍保留计算过程，且对比度可能不达标；用预设的$nav-bg-active更可控
示例：修改移动端菜单展开后的背景色，只改一个变量，而不是去翻 .nav--expanded .nav-list 里写的 #2c3e50。
为什么 @extend 在导航复用上大概率翻车
想让 .nav-link 和 .nav-link--cta 共享基础样式？别用 @extend。它会把被继承的选择器原样“拖进”目标规则，造成意料外的样式污染和编译体积膨胀。
典型翻车场景：
- 你在
.btn里@extend %reset，结果所有用了.nav-link的地方都悄悄继承了按钮的cursor: pointer - 多个组件都
@extend %flex-center，Sass 编译时会把所有匹配规则合并输出，导致 CSS 文件里出现几十行重复声明 - 当用 BEM 命名（如
.nav__link）时，@extend无法跨命名空间复用，最后还是得写两遍
替代方案：用 @mixin 包裹可复用的声明块，显式调用，哪里需要哪里加，不埋伏笔。
如何让 Sass 编译出的导航 CSS 真正适配现代浏览器，又不引入冗余前缀
别信“装个 Autoprefixer 就万事大吉”。Sass 本身不处理前缀，但你的写法会影响 Autoprefixer 效果。关键点在于：写标准属性，别手写 -webkit-；用 display: flex 而不是 display: -webkit-flex。
容易被忽略的兼容性细节：
- Flexbox 在 iOS Safari 9–11 对
flex: 1支持不稳定，建议显式写flex: 1 1 auto，Sass 里可用@mixin flex-1封装 -
gap在导航项之间很香，但 IE 完全不支持，且部分旧 Android WebView 会忽略；若需兼容，就别依赖gap做核心对齐，改用margin+:not(:last-child) - 媒体查询用
min-width而非max-width作为主断点方向，更符合移动优先逻辑，也减少 Autoprefixer 对旧式查询的误判
复杂点在于：导航常要兼顾键盘焦点、屏幕阅读器、触摸反馈，这些没法靠 Sass 解决，但 Sass 输出的类名结构是否语义清晰、是否方便 JS 绑定，决定了后续无障碍支持的成本高低。
