必须用显式、单向、分层的 @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”。开发者总想图快，在组件里补一句导入就完事，结果三个月后没人敢动按钮样式——因为没人知道它到底依赖了什么，又覆盖了什么。
