less-loader默认不启用缓存，必须手动配置cache: true并将结果存至node_modules/.cache/less-loader，否则每次构建都重解析ast和@import链；配合thread: true才能实现多线程并行读写缓存，显著提升大型项目编译速度。
less-loader 默认不启用缓存，大型项目二次构建几乎等于重编译——必须手动开启 cache 并配好路径，否则改一行变量也要跑完整个 @import 树。
less-loader 必须显式配置 cache: true
Webpack 5 的 less-loader 默认关闭磁盘缓存，每次构建都从头解析 AST、展开 mixin、重走所有 @import 路径。尤其当入口文件引入了 20+ 个 partial，且其中混有递归 mixin 时，耗时直接翻倍。
- 加
cache: true后，结果会存到node_modules/.cache/less-loader，包括已解析的 AST 和中间 CSS 片段 - 若项目用了
resolve.alias（如@styles指向src/less），缓存能识别别名路径，避免因路径写法不同（../common.lessvs@styles/common.less）导致缓存失效 - 不要依赖
cacheDirectory自定义路径——除非你明确要隔离多项目缓存，否则默认位置最稳
缓存失效的三个典型诱因
开了 cache: true 却没提速？大概率是缓存被频繁清空或未命中。
-
@import路径不一致：同一份_mixins.less，在 A 文件里写@import "mixins/_utils.less"，在 B 文件里写@import "../mixins/_utils.less"，会被视为两个文件，各自缓存，无法复用 - 全局变量或 mixin 定义顺序错乱：如果
variables.less在某个入口中被@import得太晚，缓存会认为“这次变量不同”，拒绝复用之前的结果 - 启用了
sourceMap: true：sourcemap 内容每次生成都带时间戳，导致缓存哈希值总变——开发阶段可关，生产环境再开
配合 thread: true 才真正释放缓存价值
单线程下，缓存只是“少算一次”；开了多线程，才能让多个文件并行读缓存、并行写输出，尤其对含大量 .icon-* 类的图标库项目效果明显。
-
thread: true底层用 Node.jsworker_threads，需 Node.js ≥ 12.17.0 - 不要和
cache: false搭配——多线程没缓存，每个 worker 都得自己解析一遍base/_extends.less - 检查 Webpack 构建日志：若看到
[less-loader] thread pool created with 4 workers，说明生效；若只有compiling...无 pool 提示，可能是thread配置位置错了（必须在less-loader的options里，不是 loader 数组外）
缓存不是开关一开就万事大吉——它依赖路径一致性、导入顺序、以及是否与多线程协同。一个 @import 路径多写了个 ./，整个缓存链就断了。真正省时间的地方，往往藏在那些你以为“应该一样”的路径细节里。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
