Less中@import按文本顺序内联拼接代码，变量和混合的可见性取决于导入位置；应遵循“全局→布局→组件”顺序，用(reference)只引入逻辑、(once)防重复，并注意路径解析规则。
Less中@import顺序为什么直接影响样式生效？
Less的@import不是“加载资源”，而是“内联代码拼接”——它把目标文件内容原样插入到当前语句位置，再统一编译。这意味着变量、混合（.mixin）、选择器的可见性完全取决于导入发生的文本顺序，而非文件路径或依赖声明。
常见错误现象：
-
@import "vars.less";写在.button { .mixin(); }后面，结果.mixin报错未定义 - 多个
@import引入同名变量，后导入的覆盖前导入的，但开发者误以为“先定义后使用”就安全 - 使用
@import (reference)却忘了它不参与拼接，导致样式丢失却不报错
使用场景：
- 主题切换：把
@primary-color定义放在theme-default.less里，靠导入顺序控制是否被theme-dark.less覆盖 - 组件库封装：组件
button.less必须确保@import "../mixins/border-radius.less";在自身规则之前
如何用@import实现稳定模块化？
立即学习“前端免费学习笔记（深入）”；
核心原则：按作用域层级从宽到窄排列，即「全局 → 布局 → 组件 → 页面」。
推荐顺序（从上到下逐级导入）：
-
@import "variables.less";（只含@var和.mixin定义，无CSS输出） -
@import "mixins.less";（纯.mixin，不含@import嵌套） -
@import "base/reset.less";（基础样式，如html、body重置） -
@import "layout/header.less";（布局类，影响文档流） -
@import "components/button.less";（原子组件，依赖前面的变量和混合）
注意：@import路径必须相对主入口文件，不是相对于当前文件——这是Less 3.0+默认行为，容易踩坑。比如pages/home.less里写@import "../mixins/size.less";，实际会从主入口所在目录开始解析。
@import (once)和@import (reference)的区别在哪？
@import (once)解决重复导入问题，但仅对完全相同路径生效；不同别名、不同相对路径视为不同文件，仍会重复解析。
@import (reference)是真正“只引用不输出”的方式——它把目标文件里的变量、混合注入当前作用域，但忽略所有顶层CSS规则（如.btn {}）。适合抽离utils.less这种纯逻辑文件。
容易被忽略的细节：
-
@import (reference)不能跨文件传递混合：A引用B，C引用A，C里无法直接用B定义的.mixin -
@import (inline)会把文件内容当普通文本插入，连注释都保留，适合注入第三方CSS但不编译 - 所有
@import修饰符（once/reference/inline）必须紧贴@import关键字，中间不能有空格或换行
构建时怎么验证Import顺序没出问题？
Less本身不报“变量未定义”以外的顺序错误，得靠人工检查或工具辅助。
实操建议：
- 在入口
main.less顶部加注释块，明确标注各@import段的作用，例如// === GLOBAL DEFS === - 用
lessc --lint检查语法，虽不验顺序，但能提前发现.mixin调用错位引发的解析失败 - 开发阶段临时把
@import替换成// @import "xxx"逐个启用，观察样式变化是否符合预期 - 如果用Webpack，
less-loader的paths配置会影响路径解析，务必和@import中的相对路径对齐
模块化真正的难点不在语法，而在于团队对“什么该放vars、什么该放mixins、哪些规则必须前置”的共识。一旦顺序混乱，改一个颜色可能要翻五六个文件才能定位源头。
