Less中写媒体查询需用&显式绑定父选择器，如.nav { @media (max-width: 768px) { & { display: none; } } }；避免深层嵌套、冗余循环和无效组合，合理拆分文件并使用变量管理断点与移动端样式。
Less里怎么写媒体查询才能正确编译成响应式导航栏
Less本身不处理响应式逻辑，它只是把@media原样输出到CSS，关键在于嵌套写法是否符合CSS规范。很多人写完发现断点没生效，其实是嵌套层级错位或选择器拼接出问题。
常见错误现象：@media (max-width: 768px) { .nav { display: none; } } 写在.nav块内部却忘了加&，结果编译出来变成@media (max-width: 768px) .nav { ... }（缺少花括号），浏览器直接忽略整条规则。
- 必须用
&显式表示父选择器，比如.nav { @media (max-width: 768px) { & { display: none; } } } - 如果导航有子菜单，别在
@media里重复写.nav ul，而应写& ul，否则会生成冗余选择器 - 多个断点建议抽成变量，如
@breakpoint-tablet: 768px;，避免硬编码和后期维护错乱
嵌套过深导致CSS选择器权重爆炸怎么办
Less嵌套方便，但导航栏常涉及.nav > .item > .submenu > a这种结构，一层层套下去，编译后选择器长度翻倍，不仅影响可读性，还可能意外覆盖其他样式。
使用场景：你改了.submenu的hover状态，结果全局所有a标签都变了颜色——大概率是嵌套时漏了&，让a:hover变成了全局作用域。
立即学习“前端免费学习笔记（深入）”；
- 超过三层嵌套就该警觉，优先考虑拆成独立选择器，用语义化类名代替深度依赖DOM结构
-
&只绑定最近一级父选择器，.nav { .item { &.active { color: red; } } }编译为.nav .item.active，不是.nav .item .active - 用
:extend()替代部分嵌套可降权，比如.nav-link:hover { color: #007bff; } .dropdown-item:hover:extend(.nav-link:hover) {}
如何让导航栏在移动端真正“收起-展开”而不是单纯display:none
光靠display: none切到小屏不够，用户需要点击按钮展开菜单，这涉及JS交互与CSS状态配合。Less能做的，是提前定义好.nav--open这类开关类的样式分支，避免JS操作内联样式。
性能影响：每次JS切换classList时，如果对应CSS规则写得过于具体（比如.nav.mobile .nav-list.active），重排重绘成本会上升。
- 用单个开关类控制整体状态，如
.nav.is-open { max-height: 500px; opacity: 1; }，配合transition: max-height .3s ease - 不要在
@media里写.is-open，而应在根级定义，确保PC和移动共用同一套状态逻辑 - 移动端需隐藏默认下划线、调整
line-height和padding，这些值建议用@nav-mobile-padding: 1rem;统一管理
编译后CSS体积变大，哪些Less写法最拖累性能
Less嵌套本身不慢，但某些习惯会让输出CSS膨胀数倍。比如为每个导航项单独写悬停色，又用嵌套+循环生成，最终产出几十条重复规则。
容易踩的坑：用.each()函数遍历颜色数组生成.nav-item--primary:hover等一堆类，结果实际项目只用到其中两个。
- 避免无意义的嵌套组合，如
.nav { a { &:hover { &:focus { ... } } } }，聚焦真实交互路径即可 - 慎用
!important，Less里它不会被压缩，还会干扰后续覆盖逻辑 - 开发期开
sourceMap，上线前用clean-css或构建工具自动合并重复声明，Less本身不负责压缩
最易被忽略的是：媒体查询里的样式如果和PC端完全无关，就别放在同一个.nav块里维护；拆成nav-desktop.less和nav-mobile.less，按需引入，比靠注释“屏蔽”更可靠。
