必须用显式、单向、分层的 @import 规则替代隐式依赖，因组件内直接导入 variables 会导致路径错乱、重复声明和职责混乱；index.less 须作为唯一入口统一导入，禁止组件文件自行 @import 基础文件。

大型项目里，Less 文件一旦靠“谁先写谁生效”来组织，Variable is undefined 和 Undefined mixin 就会高频报错，不是编译器问题，是导入逻辑失控了。必须用显式、单向、分层的 @import 规则替代隐式依赖。

为什么不能在组件文件里直接 @import "variables"

组件文件（比如 button.less）如果自己 @import "../variables"，会导致三类问题：

• 路径基准错乱：Webpack 的 less-loader 以当前文件为起点解析相对路径，重构目录时极易触发 Cannot find module
• 重复导入：多个组件各自导入同一份 variables，变量实际被多次声明，但 Less 不校验重复，只按最后出现的生效——值不可控
• 破坏层级职责：组件层本不该感知基础原子值从哪来，它只该消费；把导入逻辑下放，等于把“怎么组装”和“组装什么”混在一起

index.less 必须作为唯一入口，且只做导入不写样式

每个模块目录下（如 components/、pages/）都放一个 index.less，它只干两件事：声明本模块依赖、导出本模块样式。根目录的 styles/index.less 是最终聚合点。

• components/index.less 写：@import "button"; @import "modal";，不写任何规则
• styles/index.less 严格按顺序写：@import "variables"; @import "mixins"; @import "components/index"; @import "pages/dashboard";
• 业务页面（如 pages/dashboard.less）只能 @import "../index";，禁止 @import "../../mixins/flex-center"

变量覆盖静默发生，顺序即层叠优先级

Less 没有作用域，@import 就是文本拼接。后导入的同名变量会覆盖前面的，且不报错。

• 主题文件（如 themes/dark.less）必须放在组件之后导入，否则 .btn { background: #333 } 会被前面亮色规则压住
• variables.less 中定义 @border-radius: 4px;，若 themes/dark.less 后续重写为 6px，最终所有用 @border-radius 的地方都会变成 6px
• 禁止在 button.less 里写 @primary-color: #ff6b35;——这不是定制，是污染全局

嵌套 @import 是构建失败高发区

别在 button.less 里写 @import "../mixins/border-radius"。这看似方便，实则让路径依赖变得脆弱且不可追踪。

• Webpack 构建时，less-loader 会以 button.less 所在路径为基准找 ../mixins/...，一旦把 button.less 移到子目录，路径立刻失效
• 调试困难：你没法一眼看出 button 究竟依赖哪些基础能力，只能逐层打开文件翻
• 正确做法：所有基础依赖（variables、mixins）只由最上层 index.less 统一导入，组件文件保持“裸身”，只写选择器和属性

最难守住的其实是“不写那行 @import”。开发者总想图快，在组件里补一句导入就完事，结果三个月后没人敢动按钮样式——因为没人知道它到底依赖了什么，又覆盖了什么。