Less构建速度受目录结构影响，因构建工具扫描@import时路径越深、嵌套越乱、重复导入越多，解析耗时越长；需通过单点导入、无副作用导入（如@import (reference)）、规范路径（alias替代../../../）及禁用javascriptEnabled来优化。
为什么目录结构会影响Less构建速度
Less本身不编译目录，但构建工具（如Webpack、Vite）扫描@import时，路径越深、嵌套越乱、重复导入越多，解析耗时就越长。尤其当多个文件都用相对路径@import "../../base/variables"，每次变更都会触发大量无关文件的重编译——这不是语法问题，是依赖图失控的表现。
base/components/pages三层结构怎么避免重复解析
关键在“单点导入”和“无副作用导入”。base/只放variables.less、mixins.less等纯声明文件；components/下每个组件（如button/）只@import "./variables"（本地私有变量）和@import "@styles/base"（全局统一入口）；pages/禁止@import任何其他pages/文件。
-
base/variables.less必须被index.less导入且仅导入一次，不能被组件文件直接引用 - 所有
components/*/index.less是唯一合法入口，内容必须以@import "@styles/base"开头 - 构建工具需配置
resolve.alias把@styles指向src/less，杜绝../../../路径跳转
哪些@import写法会让构建变慢甚至失败
Less不报错，但会 silently 拖垮构建：动态路径（@import "@{theme}.less"）、远程URL（@import "https://xxx.css"）、未加.less后缀导致误引node_modules同名包、在非入口文件里嵌套@import形成隐式依赖链。
- 禁用
javascriptEnabled: true——它让@import可执行JS，破坏静态分析，HMR失效 - 用
@import (reference)引入纯变量/mixin文件，防止CSS重复注入导致样式覆盖冲突 - 检查
less-loader的additionalData是否意外注入了全局@import，这会让每个less文件都多一次解析
构建时如何验证目录拆分是否真起效
别只看文件数量，要查最终依赖图。Webpack用户可加stats.dependencyGraph: true，Vite用户用vite-plugin-inspect打开面板，重点看：variables.less是否只出现在一个chunk的依赖中；pages/dashboard.less是否没引用components/modal里的私有@_modal-z-index；是否有@import路径解析到node_modules里同名包。
立即学习“前端免费学习笔记（深入）”；
- CI阶段跑
grep -r "@import.*pages/" src/components/，命中即失败 - 用
less --log-level=2本地调试，观察实际解析路径是否符合预期 - 最常被忽略的是：
_前缀文件（如_mixins.less）若被错误配置为独立入口，会生成空CSS并污染缓存
