Less在大型团队中是项目稳定性必需，核心因变量管理失控和样式作用域污染。变量须集中定义于variables.less且不可覆盖，嵌套限三层，@import仅为文本拼接需人工避冲突。
Less 在大型团队协作中不是“更好用”，而是“不这么干项目就容易崩”。核心在于变量管理失控和样式作用域污染，这两点在多人并行改样式时会指数级放大。
变量定义必须集中且不可覆盖
原生 CSS 没有变量机制，团队常靠文档约定颜色名或复制十六进制值，结果是 @primary-color 在 A 组件里是 #1890ff，B 组件里被写成 #1890fe，C 组件里又变成 rgb(24, 144, 255)。Less 强制所有变量收口到 variables.less 或类似入口文件中，并依赖编译时解析顺序：
- 所有
@import必须放在文件顶部，且按依赖顺序排列（比如variables.less一定要在mixins.less之前） - 不能在局部作用域重定义同名变量（
@primary-color: #ff0000;在某个组件内部写，会污染全局） - 推荐用
@primary-color-light、@primary-color-dark这类语义化命名，而非@color-1、@color-2
嵌套规则要控制深度，否则生成的选择器过长
Less 允许无限嵌套，但编译后会生成带空格的后代选择器，比如：
.page {
.header {
.nav {
.item {
color: @primary-color;
}
}
}
}
最终输出的是 .page .header .nav .item，这种四层选择器在 Chrome DevTools 里调试困难，且易被更高权重的选择器意外覆盖。实际协作中应遵守：
立即学习“前端免费学习笔记（深入）”；
- 嵌套最多三层（对应 HTML 结构的 container → section → element）
- 避免用嵌套模拟 BEM 的修饰符，比如不要写
.btn:hover { .btn__icon { ... } }，而应直接写.btn--hover .btn__icon - 用
&显式拼接伪类或修饰符：.btn { &--large { font-size: 20px; } }
@import 是拼接，不是模块化，必须人工规避冲突
Less 的 @import 本质是文本拼接，没有作用域隔离。如果两个组件都 @import "mixins.less"，而这个文件里定义了 .clearfix()，那最终 CSS 里会出现两份重复声明。这不是 bug，是设计使然。应对方式只有：
- 所有公共
@import只允许出现在根级index.less中，子模块禁止再@import公共文件 - 用文件命名强制约束：公共变量放
base/variables.less，业务变量放feature/xxx/variables.less，后者只能引用前者，不能反向依赖 - 禁用
@import (multiple)，它会让同一个文件被插入多次，导致变量重复赋值报错
真正难处理的不是语法本身，而是当 10 个开发者同时往一个 common.less 里加 @import、改变量、提 PR 时，没人能一眼看出哪个改动破坏了按钮圆角的一致性——这得靠代码审查习惯和 CI 阶段的 CSS lint 工具配合，Less 自己不提供保障。
