@import 多次会破坏作用域隔离、隐式覆盖变量、导致构建不可控；Less 默认线性展开无缓存，需统一用 @import (once) 并确保路径完全一致。
@import multiple 会破坏作用域隔离、隐式覆盖变量、导致构建不可控，不是“多引几次”那么简单。
为什么重复 @import 同一文件却生成多份 CSS
Less 默认把每个 @import 当作独立文本拼接，不判断内容是否重复。比如 components/card.less 和 pages/home.less 都写了 @import "mixins/flex-center"，编译后 .flex-center() 的定义和调用逻辑就会被展开两次——不仅体积翻倍，还可能因第二次导入时 @gap 已被重定义，导致行为不一致。
- 现象：DevTools 里看到两段完全一样的
.flex-center规则，或某处margin突然变大 - 根本原因：
@import是线性展开，不是模块加载；没有“已导入缓存”机制 - 解决：统一用
@import (once)，且路径必须完全一致（"mixins/flex"和"./mixins/flex"被视为两个文件）
@import 顺序错乱直接让主题切换失效
Less 编译顺序严格按 @import 语句出现位置展开。如果 theme-dark.less 在 variables.less 之前被引入，里面写的 @primary-color: #1a1a1a 就会覆盖失败——因为 variables.less 里的同名变量后加载，最终生效的是浅色值。
- 常见错误：在组件文件里写
@import "../theme/dark"，以为能局部生效 - 真实后果：该组件的
@primary-color可能被其他地方的@import覆盖，且无任何警告 - 安全做法：所有主题文件只在项目唯一入口（如
main.less）顶部集中引入，并用strictImports: true让缺失文件立刻报错
混合使用 @import (reference) 和普通 @import 会让变量“消失又重现”
@import (reference) 不输出 CSS，只提供上下文；但它的变量仍参与后续所有文件的解析。如果 A 文件用 (reference) 引入 colors.less，B 文件用普通 @import 引入同一份 colors.less，那么 B 会输出变量定义 + CSS，而 A 里引用的变量实际来自 B 的那次导入——看似隔离，实则强耦合。
立即学习“前端免费学习笔记（深入）”；
- 典型症状：
components/button.less里@import (reference) "colors"，但button样式中color: @primary-color编译失败，提示 undefined - 原因：B 文件没导入 colors，或导入顺序在 button 之后，导致 reference 上下文为空
- 必须同步做两件事：所有变量收口到单个
variables.less；业务文件一律用@import (once)，禁用(reference)混用
真正难维护的从来不是“写了多少行”，而是哪一行改了会影响哪几处、谁在什么时候悄悄覆盖了哪个变量、构建产物和源码是否还能对得上——这些全藏在 @import 的展开链路里，而它不报错、不提示、不追溯。
