@import不是加载文件而是文本拼接，其顺序直接决定CSS层叠与变量生效顺序；大型项目中必须将其作为显式控制开关，按“基础→组件→覆盖”三层严格分层导入入口文件。
直接结论：@import 不是“加载文件”，而是“拼接文本”；大型项目里，它必须被当作 CSS 层叠顺序的显式控制开关来用，而不是模块依赖声明。
为什么 @import 顺序 = 样式生效顺序
Less 没有作用域，@import 就是把目标文件内容原样插入当前位置。最终 CSS 的声明顺序，完全由 @import 在入口文件里的书写顺序决定——后导入的 .btn 规则会覆盖前面的同名规则，变量也会被静默重写。
- 常见错误：
variables.less放在components/button.less后面导入 →@primary-color在 button 里引用时报Variable is undefined - 主题覆盖失效：暗色模式
themes/dark.less必须放在所有组件样式之后，否则.btn { background: #333 }被前面的亮色规则压住 - mixins 失效：如果
mixins.less用@import (reference)导入，但某个组件没显式@import "mixins"，调用.flex-center()就报Undefined mixin
哪些文件该放进主 index.less？只放“指挥层”
根目录 styles/index.less 是唯一可接受相对路径、且必须严格分层的聚合点。它不写样式，只做三件事：声明基础、暴露接口、控制流向。
- 第一梯队（不可变基础）：
@import "variables"、@import "mixins"、@import "reset" - 第二梯队（可复用逻辑）：
@import "components/index"（该文件再统一导入 button、modal 等） - 第三梯队（覆盖层）：
@import "themes/dark"、@import "overrides/vendor"—— 必须在组件之后 - 禁止行为：在
index.less里直接@import "pages/home"或@import "../components/button"，会导致首屏体积暴涨、热更新变慢
为什么不能在组件文件里写 @import "../variables"
组件层（如 components/button/button.less）写 @import "../variables" 看似方便，实则破坏整个架构的可控性。
立即学习“前端免费学习笔记（深入）”；
- 路径基准错乱：
less-loader以当前文件为起点解析../variables，一旦把button.less移到components/form/button，立刻报Cannot find module - 重复声明变量：多个组件各自导入同一份
variables，Less 不校验重复，只按最后出现的生效 —— 值不可控 - 职责混杂：组件不该知道变量从哪来，只该消费；把导入逻辑下放，等于把“怎么组装”和“组装什么”混在一起
- 调试困难：你没法一眼看出
@border-radius最终来自哪次导入，grep 也找不到源头
@import (reference) 该用在哪、不该用在哪
@import (reference) 的本质是“只提供 mixin/变量，不输出 CSS”。它不是万能解耦工具，用错地方反而让问题更隐蔽。
- 适合场景：
mixins.less、functions.less这类纯逻辑文件，只封装.text-ellipsis()、.make-grid()，不带任何选择器 - 不适合场景：
components/button.less—— 它既要输出.btn规则，又要调用.flex-center()，用(reference)会导致样式丢失 - 构建陷阱：Webpack 的
less-loader对(reference)缓存不稳定，热更新后 mixin 可能不生效，需重启 dev server - 替代方案：统一用普通
@import，靠index.less控制顺序，比分散使用(reference)更易追踪、更少意外
真正难的不是写多少 @import，而是让每个 @import 都有明确的“谁导入谁、为什么导入、导入后谁负责清理”。路径别名、原子化分层、入口单点控制，这些都不是约束，是给混乱留下的逃生通道。
