Less本身无插件机制，所谓“插件”实为构建工具或lessc对接的第三方处理器；真正提升编译性能的是Webpack中less-loader的cache与thread选项，而非less-plugin-*类后处理插件。
Less 本身不支持插件机制，所谓“Less 插件”实际是构建工具（如 Webpack、Vite）或命令行工具（lessc）对接的第三方处理器，比如 less-plugin-clean-css 或 postcss 链路。真正影响编译性能的不是插件本身，而是你是否让它们跳过重复工作。
lessc 命令行里加 --clean-css 不提速，反而可能拖慢
lessc --clean-css 是把 CSS 输出直接交给 clean-css 处理，但它发生在每次编译末尾——也就是说，Less 仍要全量解析 AST、重算变量、生成未压缩 CSS，最后才压缩。这没减少编译核心耗时，只省了后续手动压缩步骤。
- 仅在上线前一次性构建时用，开发期禁用
- 参数必须整体传入：
--clean-css="--s1 --advanced"，拆开就失效 - 它不缓存、不复用 AST，和
lessc --no-source-map这类开关不在同一优化层级
Webpack 中 less-loader 的 cache 和 thread 才是真插件级加速
Webpack 的 less-loader 支持 cache: true 和 thread: true，这两个选项背后调用了 Node.js 的 worker_threads 和文件级 AST 缓存，属于构建系统层面的“插件化加速”。
-
cache: true启用后，会在node_modules/.cache/less-loader存 AST 和 CSS，二次构建跳过 tokenize + parse -
thread: true把 mixin 展开、变量求值等 CPU 密集操作扔进 worker，避免阻塞主线程 - 二者必须同时开：单开
cache对含 50+ mixin 的文件仍卡在单核；单开thread每次都重解析 AST，白费线程
别信 “less-plugin-*” 能提升编译速度
社区里叫 less-plugin-xxx 的包（如 less-plugin-autoprefix）本质是 hook 到 less.render() 的 AST 遍历阶段做后处理，它们运行在编译完成之后，不参与解析、作用域计算或依赖追踪——也就是不碰真正拖慢 Less 的三件事：@import 全量重载、变量跨文件求值、source map 路径遍历。
立即学习“前端免费学习笔记（深入）”；
- 这类插件适合做 post-CSS 处理（如加前缀），但不能替代
postcss链路 - 启用
javascriptEnabled: true才能加载它们，而该选项会让缓存失效、AST 不可预测，开发期应禁用 - CI 环境中更不该用：动态执行 JS 代码带来安全风险，且无法做静态依赖分析
真正决定编译快慢的，从来不是插件多寡，而是你有没有切断无效依赖——比如 @import "node_modules/bootstrap/less/mixins.less" 这种路径，会让 Less 每次都去读取并解析那个根本不会变的文件。关掉 source map、收敛 @import 路径、显式控制 paths，比装十个插件都管用。
