lessc 默认编译慢是因为默认开启源码映射、严格语法检查及每次重复解析全部@import依赖树；watch卡住因监听粒度粗，递归扫描含node_modules的无关文件；输出冗余因未压缩、不合并选择器；API调用比命令行更可控但需手动缓存。
为什么 lessc 默认编译慢？
因为默认开启源码映射（--source-map）、严格语法检查、以及每次编译都重新解析全部 @import 依赖树。尤其在大型项目里，@import 嵌套深、变量复用多时，重复解析开销明显。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 关闭非调试阶段的源码映射：
lessc --no-source-map - 用
--strict-math=on替代默认的off，避免运行时计算推导，提前暴露数学表达式错误 - 避免在根文件里
@import全量组件库（比如@import "bootstrap/less/bootstrap.less"），改用按需引入具体模块
lessc 的 watch 模式为什么常卡住？
不是 watch 本身慢，而是默认监听粒度太粗：它会递归扫描所有 @import 路径下的文件变更，包括 node_modules 里的 less 文件——而这些文件根本不会动，却白白触发重编译。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 显式限定监听范围：
lessc --watch --include-path=./src/less ./src/less/main.less - 加
--disable-dotfiles防止监听隐藏文件（如.gitignore同级的.less备份） - 若用 Webpack，别直接套
less-loader+watch，优先配cache: true和thread: true，比纯命令行更稳
如何让 lessc 编译结果更小、更可控？
默认输出未压缩、带空行和注释，且不处理重复选择器合并——这在生产环境就是冗余字节。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 上线前必加压缩：
lessc --clean-css="--s1 --advanced --compatibility=ie8" main.less（注意--clean-css参数必须整体传给 clean-css，不能拆） - 用
--modify-var="theme-color=#007bff"动态覆盖变量，比维护多套主题文件更轻量 - 慎用
--global-vars：它会在编译前注入全局作用域，可能意外覆盖局部@variable，调试时容易误判来源
Node.js 环境下 less 包调用比命令行更快吗？
不一定快，但更可控。命令行本质是启动新进程跑 Node，有启动开销；而 API 调用可复用同一进程、缓存 AST、支持增量编译。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 在构建脚本中优先用 JS API：
less.render()配paths和math选项，比反复 spawnlessc进程省 200–400ms/次 - 启用缓存需手动管理：
less.render()不自动缓存，得自己用Map存上一次的tree和css，再比对文件 mtime - 注意
javascriptEnabled: true是危险开关，仅限可信代码，线上构建应禁用
真正影响速度的从来不是语法糖或配置项堆砌，而是 import 路径是否收敛、变量是否被跨文件循环引用、以及你有没有在 watch 里把 node_modules 当成监听目标——这些地方一松动，优化再多参数也白搭。
