Less嵌套应控制在3层内，仅用于语义强关联的组件内部；避免布局类、工具类及媒体查询深层嵌套，慎用&拼接与变量作用域，优先通过文件拆分提升可维护性。
Less嵌套语法怎么写才不踩坑
嵌套本身不难，但写多了容易生成过深的选择器、重复的父级引用，或者误以为嵌套能替代BEM类名逻辑。Less嵌套本质是语法糖，编译后仍生成标准CSS，所以它解决的是「人看代码」的问题，不是「浏览器渲染」的问题。
关键原则：只在语义强关联、层级稳定、且确实需要视觉嵌套表达的场景用嵌套；避免为“看起来整齐”而嵌套。
-
&表示当前选择器自身，比如.btn { &--primary {} }编译为.btn.btn--primary - 子选择器用空格（如
.card { .title {} }→.card .title），不是>；想用后代还是子代，得靠你心里有数，Less不校验语义 - 嵌套超过 3 层（如
.a { .b { .c { .d {} } } }）会显著增加选择器权重，也难维护，建议拆成独立类或用compose（如果用 CSS Modules）或 BEM 命名收口
什么时候该用嵌套，什么时候该收手
典型适合嵌套的场景：组件内部样式强耦合，比如表单控件的状态组合、卡片内标题/描述/操作区的布局约束；不适合的场景：跨模块复用的原子类（如 .text-center）、工具类、响应式断点切换。
- ✅ 适合：
.modal { &__header {}, &__body {}, &__footer {} }—— 语义清晰，命名收敛，结构固定 - ❌ 不推荐：
.container { .row { .col-6 {} } }—— 这类布局类本应解耦，嵌套反而掩盖了职责分离问题 - ⚠️ 高危：
@media (max-width: 768px) { .nav { li { a {} } } }—— 媒体查询里再嵌套三层，调试时定位困难，且编译后选择器冗长（@media (max-width: 768px) .nav li a），易被更高权重规则覆盖
嵌套中访问父级属性和变量的常见误用
Less 支持在嵌套块里直接调用上层定义的变量，但很多人忽略作用域链和变量重定义风险。更隐蔽的问题是用 & 拼接伪类或属性时，忘了加空格或括号，导致编译出错或意料外的选择器。
立即学习“前端免费学习笔记（深入）”；
-
.link { color: @primary-color; &:hover { color: darken(@primary-color, 10%); } }✅ 安全，变量在作用域内 -
.item { &::before { content: "→"; } &.is-active { &::before { content: "✓"; } } }✅ 正确拼接，第二层&指向.item.is-active -
.box { width: 200px; .box-inner { width: @width; } }❌ 报错：@width未定义 —— Less 不自动暴露父级属性名，必须显式定义变量
编译后CSS体积和选择器权重的隐性代价
嵌套看着省事，但每多一层，就多一重父选择器前缀。一个 .page { .section { .content { p {} } } } 会生成 .page .section .content p，权重高达 0,0,3,0，比 .content p 难覆盖得多。上线后排查样式冲突，第一眼看到的往往是这种“嵌套遗产”。
- 用
lessc --lint或 VS Code 插件检查嵌套深度，建议设阈值 ≤ 3 - CI 中可加简单脚本 grep 编译后CSS里的
{\s*.*{统计嵌套层级（非精确但够用） - 真正要提升可读性，不如配合
@import拆文件 + 清晰目录结构（如components/card.less），比死磕嵌套层数实在
嵌套不是银弹，它让写样式变快，但也让改样式变重——尤其当别人接手、或你三个月后回来看的时候，最常卡住的不是语法，而是“这里为什么必须套四层”。
