结论：别用顶层嵌套媒体查询写导航栏，否则编译出非法CSS或高权重选择器；真正该做的是用@mixin respond-to封装断点、按语义分层命名（.nav/.nav-list/.nav-item）、把移动端折叠逻辑抽成独立状态类（如.nav--mobile），再配合@content注入定制样式。
直接说结论：别用顶层嵌套媒体查询写导航栏，否则编译出非法 CSS 或高权重选择器；真正该做的是用 @mixin respond-to 封装断点、按语义分层命名（.nav / .nav-list / .nav-item）、把移动端折叠逻辑抽成独立状态类（如 .nav--mobile），再配合 @content 注入定制样式。
为什么 @media 不能塞进 .nav 里嵌套写
常见错误是这样写：
.nav {
display: flex;
@media (max-width: 768px) {
flex-direction: column;
&__item { font-size: 14px; }
}
}
结果 Sass 编译器要么报错（.nav@media 是非法语法），要么生成类似 .nav .nav__item 这种冗余选择器——层级越深，CSS 权重越高，后面想覆盖反而要加更多 !important 或更长的选择器。
- 嵌套只省父选择器重复，不省断点逻辑；媒体查询本质是「条件」，不是「结构」
- 所有组件共用同一套断点值，硬编码在每个
@media里，改一次得全局搜768px - 移动端折叠行为（比如汉堡菜单展开）和基础布局耦合，JS 切换类名时样式响应滞后或失效
怎么用 @mixin respond-to 管理断点
断点不是像素值，而是语义层级。定义统一变量 + 混合宏，才是可维护的起点：
立即学习“前端免费学习笔记（深入）”；
$breakpoints: ("sm": 576px, "md": 768px, "lg": 992px);
@mixin respond-to($breakpoint) {
@media (min-width: map-get($breakpoints, $breakpoint)) {
@content;
}
}
关键点：
- 必须用
min-width，避免断点重叠（比如max-width: 768px和max-width: 769px之间留缝隙） -
map-get($breakpoints, md)比硬写768px更安全——单位不会丢，且一处改，全项目生效 - 桌面默认样式写在常规规则里，移动端适配用
@include respond-to(md)包裹，而不是反过来
导航结构怎么分层才不乱
语义化命名比嵌套更深更重要。推荐结构：
<nav class="nav">
<ul class="nav-list">
<li class="nav-item">
<a href="https://www.php.cn/link/93ac0c50dd620dc7b88e5fe05c70e15b" class="nav-link">首页</a>
</li>
</ul>
<button class="nav-toggle" aria-expanded="false"></button>
</nav>
对应 Sass 分层：
-
.nav：控制整体容器行为（比如position: relative） -
.nav-list：只管流式布局（display: flex/flex-wrap: wrap） -
.nav-item：负责单项间距和状态（margin-inline-end） -
.nav-link：专注文字、颜色、hover/focus 样式 -
.nav--mobile或.nav-toggle：单独定义汉堡按钮和菜单显隐逻辑，不混在基础样式里
为什么 @content 在导航混合宏里不能少
纯参数化混合宏（比如 @mixin nav-layout($direction)）没法应对真实需求：桌面端要下拉箭头，移动端要滑动动画，甚至暗黑模式下要切换文字颜色。
正确做法是定义带钩子的宏：
@mixin nav-layout-desktop {
display: flex;
flex-direction: row;
@content;
}
@include nav-layout-desktop {
.nav-link::after { content: "▼"; }
}
这样使用者能透传任意样式块，而核心布局逻辑保持稳定。没有 @content，就只能复制粘贴整段样式，违背复用初衷。
最易被忽略的点：移动端菜单的 max-height: 0 + overflow: hidden 动画，必须配合 JS 在 resize 事件中监听断点变化——Sass 只管定义状态，不感知屏幕实时尺寸。
