Less中@import顺序决定CSS层叠顺序，变量和Mixin首次声明生效，重复声明不覆盖除非加!default；additionalData会破坏导入顺序，全局注入应显式@import而非依赖配置。
Less文件里@import的顺序就是CSS加载顺序
Less编译时，@import不是运行时加载，而是静态合并——所有@import语句按书写顺序把内容“拼”进主文件，最终输出一份CSS。所以覆盖逻辑完全取决于导入顺序：后导入的样式规则会自然覆盖先导入的同名选择器。
常见错误现象：改了变量值但样式没变；写了.btn { color: red; }却还是蓝色；组件库样式意外被业务样式盖掉。
- 必须把基础变量、mixin定义的文件放在最前面（如
@import "variables.less";） - 通用工具类、重置样式紧随其后
- 具体组件或页面样式放最后，确保它们能覆盖前面的通用规则
- 避免在
@import内部再嵌套@import，容易模糊依赖关系
用lessc命令行编译时，入口文件决定主顺序
如果你用lessc index.less > bundle.css，那index.less里写的@import顺序就是最终CSS的层叠顺序。它不关心文件物理路径深浅，只认@import语句出现的先后。
使用场景：多人协作中有人把@import "components/button.less";写在@import "base/reset.less";前面，结果按钮重置失效。
- 不要靠文件名排序（比如
_01-base.less、_02-layout.less）来管理顺序，less不识别这种命名 -
lessc默认不支持@import (multiple)之类扩展语法，老版本遇到就报错Unrecognised input - 若用Webpack +
less-loader，注意lessOptions.paths只影响路径解析，不影响导入顺序
变量和Mixin的声明位置比导入顺序更关键
Less里变量和Mixin不是“定义即生效”，而是“首次声明才生效”。后面重复声明同名变量，不会覆盖前面的值——除非加!default标记。
性能影响：无运行时开销，但错误的变量覆盖会导致样式生成错乱，调试时很难定位是变量没生效，还是选择器被覆盖了。
-
@primary-color: #007bff;→ 后面再写@primary-color: #dc3545;不会改变已使用的值 - 正确做法：
@primary-color: #dc3545 !default;，只在未定义时赋值 - Mixin也一样：
.flex-center() { display: flex; justify-content: center; }重复定义会报错，不是覆盖 - 想实现“可覆盖”的Mixin？得用参数+条件判断，而不是依赖导入顺序
Webpack项目里less-loader的additionalData会破坏原有顺序
如果配置了additionalData（比如自动注入全局变量），它会被插到每个Less文件最开头，相当于所有文件都隐式@import了一份内容。这会干扰你精心设计的导入链。
典型问题：你在theme.less里定义了@bg: #f8f9fa;，但additionalData里又写了@bg: #fff;，结果所有文件都优先用了白色背景。
- 检查
less-loader配置里是否有additionalData或javascriptEnabled（后者在v7+已废弃，开启可能引发解析异常） - 想全局注入变量？改用
paths+ 单独的global-vars.less，并在每个入口文件第一行显式@import - Vue项目中
也会受additionalData影响，且无法单独关闭
真正难处理的不是“怎么让A覆盖B”，而是当多个团队共用一套Less基建时，没人记得清谁在哪个@import里悄悄改了@link-color。这时候光看CSS输出已经看不出来源，得靠编译前的AST分析或者加注释标记导入意图。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
