Less嵌套不管理结构，真正关键在于清晰划分组件边界；应避免将布局容器作为父级嵌套，改用独立BEM块（如.app-sidebar）并合理使用&处理状态与伪类，深度超3层须拆分，媒体查询和工具类须平级书写。
Less嵌套本身不管理结构，它只帮你少敲几遍父类名；真正管结构的是你对组件边界的判断——后台系统里，一个 .sidebar 和一个 .main-content 从来就不是父子关系，硬套嵌套只会让编译出的选择器权重失控、调试时找不到源码位置。
嵌套前先划清组件边界，别把布局容器当父级
后台系统常见错误是把 .layout 当作顶层容器，然后把 .header、.sidebar、.main 全塞进它的嵌套块里。结果编译出 .layout .header、.layout .sidebar 这类选择器，权重涨了，但语义没增，反而让 .sidebar 的样式强依赖 .layout 存在。
- 正确做法：每个区域定义独立 BEM 块，如
.app-header、.app-sidebar、.app-main，再用 Less 嵌套收口：.app-sidebar { &__logo {}, &__nav {} } - 避免写
.layout { .header {}, .sidebar {} }—— 这等于告诉 Less：“所有子选择器都必须带.layout前缀”，后续任何覆盖都要加权竞争 - 布局类（如
.grid-col-4）坚决不进嵌套，它们本该是原子工具，和上下文无关
& 必须显式出现，否则伪类/状态类会失效
后台系统里按钮、表格行、折叠面板的状态组合极多，但 :hover、:active、.is-collapsed 这些如果漏写 &，就会编译成全局规则，污染其他模块。
- 错误：
.btn { hover { color: red; } }→ 编译为.btn hover（无效选择器） - 正确：
.btn { &:hover { color: red; } &.is-disabled { opacity: 0.5; } }→ 分别生成.btn:hover和.btn.is-disabled - 复合状态慎用嵌套：
&:hover.is-active合法，但&:hover &.is-active会生成.btn:hover .btn.is-active，逻辑错乱
嵌套深度超过 3 层时，立刻拆成独立文件或 BEM 子块
后台的表格、表单、弹窗常有多层嵌套需求，比如 .modal { .form { .field { .input {} } } }。这种写法编译后是 .modal .form .field .input，权重 0-3-0，Chrome DevTools 里点开样式面板根本定位不到源码行号。
立即学习“前端免费学习笔记（深入）”；
- 推荐方案：用 BEM 拆平层级，
.modal__form、.form__field、.field__input各自独立定义，再用嵌套组织内部状态：.field { &__input { &:focus {} } } - 超过 3 层的嵌套，
lessc --lint会警告，但更关键的是：你已经分不清这个.item是属于菜单、列表还是弹窗了 - 如果真需要复用深层结构（如树形控件），用
.mixin()+ 参数封装，而不是靠缩进“视觉对齐”
媒体查询和工具类绝不能塞进嵌套块里
后台系统要适配大屏和小屏操作，但把 @media 塞进 .sidebar 块里，会导致同一段 CSS 在多个断点中重复输出，体积翻倍，且移动端的 .sidebar__item 样式可能被其他地方同名类意外覆盖。
- 正确姿势：断点变量统一定义在
variables.less，媒体查询平级书写：@media (max-width: 768px) { .app-sidebar { display: none; } } - 工具类（
.text-truncate、.p-2）必须保持无上下文，嵌套进去就失去复用价值 - 第三方组件（如
.ant-table）样式不要嵌套修改，直接用属性选择器或提高特异性：[class^="ant-table"] .ant-table-cell比.app-main { .ant-table { ... } }更可控
后台系统的 CSS 结构难点不在嵌套语法，而在组件职责是否切得干净；一旦开始怀疑“这个 .item 到底该归谁管”，说明嵌套已变成掩盖设计缺陷的遮羞布，这时候该打开文件夹新建一个 components/tree/，而不是再缩进一层。
