大型项目less目录结构应采用原子化三层结构：variables→mixins→components/pages，入口index.less统一控制导入顺序，严禁嵌套import和隐式覆盖，确保变量唯一、mixin不泄漏、样式可追溯。
大型项目里，Less目录结构一旦失控，改个按钮圆角都要 grep 十分钟——根本不是“能不能拆”，而是“怎么拆才不互相污染”。原子化拆分 + 入口聚合是目前最可控的路径，但必须守住三条线：变量不重复、mixin 不泄漏、样式不隐式覆盖。
为什么不能直接按页面或组件建文件夹
新手常把 pages/home.less、pages/profile.less 当成天然模块，结果很快发现：@primary-color 在 home 里定义一次，profile 又定义一次；.btn 的 .btn-primary 嵌套规则在两个文件里各写一遍；Webpack 构建时报 Recursive import。这不是组织问题，是职责混杂。
- 页面文件不该管颜色、间距、断点这些基础设定
- 组件文件不该重复声明通用工具 mixin（比如
.clearfix） - 所有
@import必须有明确流向，不能靠“谁先加载谁生效”来赌顺序
原子化三层结构：variables → mixins → components/pages
每一层只做一件事，且上层不依赖下层，下层不感知上层：
-
styles/variables.less：只放@color-primary、@spacing-md、@breakpoint-lg这类纯值变量，不带任何样式逻辑 -
styles/mixins.less：只封装可复用的行为，如.flex-center()、.text-ellipsis()、.make-type-scale()，不输出任何选择器 -
styles/components/button.less、styles/pages/dashboard.less：只写具体样式，且内部禁止再@import "variables"或@import "mixins"
入口文件 styles/index.less 统一控制流向：
@import "variables";<br>@import "mixins";<br>@import "components/button";<br>@import "components/modal";<br>@import "pages/dashboard";
@import 顺序就是 CSS 层叠顺序，别指望“作用域”
Less 没有模块作用域，@import 就是文本拼接。后导入的 .btn 规则会覆盖先导入的同名规则——这不是 bug，是 CSS 本性。
- 变量覆盖静默发生：
variables.less定义@border-radius: 4px，themes/dark.less后续重定义为6px，最终生效的是后者 - 组件样式必须在主题文件之前导入，否则暗色模式的
.btn { background: #333 }会被前面的亮色规则压住 - 禁用嵌套
@import：不要在button.less里写@import "../mixins/border-radius"，路径基准会错乱，Webpack less-loader 极易报Cannot find module
容易被忽略的构建与调试陷阱
结构再干净，编译链出问题也白搭：
- VS Code 的
easy less扩展默认不支持@import (reference)，如果用了这个参数，保存时不会触发编译，得切到命令行用lessc - Webpack 项目中，
less-loader的paths配置必须指向src/styles，否则@import "mixins/utils"会找不到 - 开发时打开
sourceMap很重要——否则 Chrome DevTools 里点样式，跳转的是编译后的index.css第 1289 行，而不是button.less第 42 行 -
@import (reference)看似省事，但它让.button-primary这类业务样式完全不出现在最终 CSS 里，只留 mixin 可调；调试时查不到对应规则，团队协作时新人极易误以为“样式没生效”其实是根本没引入
真正难的不是拆分，是让每个 @import 都有迹可循、每个变量都有唯一源头、每次修改都只影响它该影响的地方。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
