嵌套超过3层会导致css选择器权重失控、覆盖困难、样式外溢；应改用bem命名、mixin封装、平级结构及职责分离的模块化方案。
Less嵌套层级超过3层时，CSS选择器权重会失控
Less里每多一层嵌套，编译出的选择器就多一个类名或标签名，最终生成的CSS权重直线上升。比如 .card { .header { h1 { color: red; } } } 编译后是 .card .header h1，权重为 0-2-1；如果再套一层，变成 .card .header .title h1（0-3-1），后续想用单个类名覆盖它就得写两个类、甚至加 !important —— 这不是在写样式，是在打补丁。
- 实际项目中，嵌套超过3层几乎必然导致局部样式外溢或覆盖困难
- 组件级作用域（如 BEM）比嵌套更可控：用
.card__header替代.card .header，权重恒为 0-1-0 - Less 的
&符号能缓解但不根治：比如.btn { &--primary { ... } }是安全的，但.modal { .overlay { .content { ... } } }就危险
用 extract() 和 merge() 拆分逻辑，别靠嵌套组织代码结构
嵌套常被误当作“代码分组”手段，但它解决的是选择器生成问题，不是可维护性问题。真正该拆的是样式职责：颜色、间距、状态、响应式应分文件管理，用 Less 的 @import + .less 后缀导入，而不是缩进对齐。
-
extract()适合抽离重复数值：比如@spacing-xs: 4px; @spacing-sm: 8px;，避免在嵌套里反复写margin: 8px -
merge()（需 Less 4.0+）可用于合并同名规则，但要注意它只合并声明块，不降权重 —— 别指望它“简化嵌套” - 常见错误：把媒体查询塞进深层嵌套里，结果编译出
@media (min-width: 768px) { .a .b .c .d { ... } }，既难读又难调试
编译后CSS体积暴增？检查 extend() 和嵌套的叠加效应
extend() 看似节省代码，但和嵌套混用时极易产生冗余选择器。比如 .icon { &:extend(.visually-hidden all) } 在嵌套块里使用，Less 会把 .visually-hidden 的所有匹配规则都复制进当前上下文，导致同样样式在多个父级下重复输出。
- 运行
lessc --clean-css只能压缩空格，无法消除语义重复；真正要减体积，得先砍掉无意义嵌套 - 用 Chrome DevTools 的 “Coverage” 面板查未用CSS，常会发现大量
.page .layout .main .content .text p类似长链，根源就是嵌套失控 - 替代方案：用 Mixin 封装行为（如
.text-emphasis() { color: @brand-primary; font-weight: 600; }），调用时不增加选择器长度
Vue/React 项目里用 Less，别让 scoped 样式掩盖嵌套问题
Vue 的 <style scoped></style> 或 React 的 CSS Modules 会给选择器自动加属性哈希（如 .btn[data-v-abc123]），看起来“隔离了”，但嵌套依然会让权重变高、影响子组件透传样式，而且开发时看不到真实选择器结构，调试更费劲。
- scoped 模式下，
.container { .item { ... } }编译成.container[data-v-abc] .item[data-v-abc]，权重翻倍，且无法被外部.item.highlight覆盖 - 推荐写法：顶层用唯一组件名（
.my-component），内部全部平级命名（.my-component__header,.my-component__body），禁用嵌套 - 容易忽略的一点：Less 的
@value: value;变量在 scoped 下仍全局生效，但嵌套里的变量作用域混乱，调试时很难定位来源
嵌套本身不是错，错在把它当作用域、复用、组织的默认解法。真正的高性能CSS，是让选择器尽可能短、权重尽可能低、变更尽可能局部 —— 这些目标，嵌套越深，离得越远。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
