应使用 Less Mixin 封装响应式导航栏逻辑，通过参数化断点（如 mobile/tablet/desktop）和条件判断（when）统一管理媒体查询，避免重复书写 @media，提升可维护性与复用性。
Less里怎么写响应式导航栏的断点切换逻辑
直接用 @media 套在每个导航样式块里，很快会失控。真正省事的做法是把断点和布局逻辑抽成 .nav-responsive() Mixin，传入不同断点值或模式参数，让同一套导航结构在 mobile / tablet / desktop 下自动适配。
关键不是“怎么写媒体查询”，而是“怎么避免重复写 @media (max-width: 768px) 十几次”。Less 的 Mixin 支持参数默认值、条件判断和嵌套规则，正好用来封装响应式行为。
- 用
@breakpoint-mobile: 480px、@breakpoint-tablet: 768px等变量统一管理断点，别硬编码 - Mixin 内部用
when判断模式（如.nav-responsive(desktop) when (@mode = desktop)），比堆@media更易维护 - 移动端折叠菜单的
display: none和flex-direction: column必须成对出现，漏掉一个就会导致布局错乱
为什么用Mixin封装比CSS-in-JS或PostCSS更合适
如果你项目已用 Less 且导航栏结构稳定，额外引入 JS 控制类名或 PostCSS 插件反而增加构建链路和调试成本。Less Mixin 在编译期就生成对应 CSS，无运行时开销，也兼容老版本 IE（只要输出的是标准 CSS）。
但注意：Mixin 不是万能的。它无法响应浏览器窗口实时 resize —— 这部分仍需靠媒体查询本身，Mixin 只是帮你写得更干净。
立即学习“前端免费学习笔记（深入）”；
- 不支持动态计算断点（比如根据容器宽度而非视口），
@media是唯一可靠方案 - 如果导航需要 JS 控制展开/收起（如汉堡菜单），Mixin 只管样式，JS 仍要单独处理
.nav-open类切换 - Webpack 的
less-loader默认开启javascriptEnabled: false，若 Mixin 里用了 JS 表达式（如unit(@val, px)），需手动打开该选项
常见错误：Mixin调用后样式没生效
最常踩的坑不是语法错，而是作用域和执行顺序问题。Less 编译器按定义顺序解析 Mixin，但调用位置决定了它注入样式的上下文。
- 在
.nav规则内部调用.nav-responsive()，结果只影响该选择器下的子元素；想控制整个导航组件，应在顶层调用 - 忘记给 Mixin 参数传值，又没设默认值，会导致整段规则被跳过（Less 不报错，静默失效）
- 使用了
!important覆盖 Mixin 生成的样式，结果在某个断点下优先级反超，造成“明明写了却没反应”的假象 - 示例错误写法：
.nav { .nav-responsive(); }→ 正确应为：.nav { .nav-responsive(mobile); }，否则参数匹配失败
移动端汉堡菜单的Less封装要点
这不是单纯改 display，还涉及 z-index 层级、过渡动画、焦点管理等。Mixin 要覆盖这些细节，否则在 iOS Safari 上容易点击无响应或菜单闪退。
- 必须显式设置
position: relative给.nav，否则.nav-menu的position: absolute会相对 body 定位，遮挡错位 - 过渡动画统一用
transition: transform 0.3s ease, opacity 0.2s ease，别只写all，避免触发重排 - 为可访问性，Mixin 应自动添加
aria-expanded对应的样式钩子，例如：[aria-expanded="false"] { .nav-menu { opacity: 0; transform: translateY(-10px); } } - iOS Safari 对
transform: translateZ(0)敏感，加在.nav-menu上可避免闪烁，但别加在根节点上，否则可能引发输入框失焦
