Less嵌套需手动收束&作用域，否则子选择器成全局；应优先用BEM前缀、层级约定和@import顺序控制优先级，避免!important和含选择器的mixin引发冲突。
Less嵌套怎么避免意外覆盖全局样式
嵌套本身不解决冲突，反而容易放大污染——& 的作用范围必须手动收束，否则子选择器会悄悄变成全局选择器。
- 默认嵌套生成的是后代选择器（
.a .b），不是作用域隔离；想真正“隔离”，得用:local（仅 CSS Modules）或靠命名约定 + 嵌套层级控制 - 常见错误：写
.card { .title { color: red; } }，结果编译出.card .title，但若页面其他地方也有.title，照样被影响 - 更安全的做法是加前缀或用
&__elementBEM 风格：.card { &__title { color: red; } }→ 编译为.card__title，物理级隔离 - 慎用
&:hover之类展开，一旦父类名变动，所有子规则全失效；建议只对明确属于该组件的交互状态才用
为什么 !important 在 Less 里不是解药
加 !important 能压住优先级，但会让后续维护者无法用常规方式覆盖——它把层叠逻辑从“可预测”变成“必须全局搜索”。
- Less 编译后仍是普通 CSS，
!important不会因为嵌套就变弱或变强，它只看最终输出的选择器权重 - 多人协作时，A 在
.btn { color: blue !important; }，B 想改按钮文字颜色，只能也加!important或提高选择器权重（比如加 ID），恶性循环 - 真正该做的是提前约定层级：基础样式（reset/typography）→ 布局组件（
.grid）→ 业务组件（.user-card），靠顺序和命名压制，而不是靠感叹号硬顶
@import 的加载顺序如何影响样式优先级
Less 的 @import 不是“引入文件”，而是“内联插入代码”，顺序直接决定 CSS 规则在最终文件里的位置，从而影响层叠结果。
- 后
@import的文件里定义的同名规则，会出现在前面的规则之后 → 自然覆盖（前提是选择器权重相同） - 错误示范：
@import "base.less"; @import "theme.less";，但theme.less里写了.btn { background: red; }，而base.less里有更具体的选择器.btn.is-primary { background: blue; }，那依然不会被覆盖 - 可靠做法：把重置、工具类放最前，组件样式居中，页面级定制放最后；同时避免在不同
@import文件里重复定义同一类选择器 - 注意
@import (reference)：它不输出 CSS，只提供变量/mixin，不会参与层叠，适合抽离公共逻辑
变量和 mixin 真的能减少冲突吗
能，但前提是它们只封装“值”或“结构”，不封装“选择器”。一旦 mixin 里带选择器，就等于批量注入潜在冲突点。
- 安全用法：
.size(@w, @h) { width: @w; height: @h; }→ 只输出声明，无选择器，零风险 - 危险用法：
.clearfix() { &:after { content: ""; display: table; clear: both; } }→ 每次调用都插入一段选择器，如果多个组件都调.clearfix()，就会产生多份&:after规则，可能互相干扰 - 变量命名要带作用域前缀，比如
@card-title-color而非@title-color，防止跨组件误用 - 混合使用
extend要格外小心：.icon { &:before { ... } } .btn-icon:extend(.icon) {}会把.icon的所有规则复制进.btn-icon，包括可能冲突的伪元素
事情说清了就结束。真正难的不是语法，是团队是否对“谁负责哪块样式边界”有共识——没有这层约束，再好的 Less 写法也挡不住一个随意的 .global-header .title。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
