Less编译速度普遍慢于Dart Sass，根本原因在于执行引擎与架构差异：Less运行于Node.js的V8引擎，解析、递归、插值等均受JS运行时开销制约；Dart Sass通过AOT编译为原生二进制，词法语法解析高度定制，支持作用域哈希查找和@use静态分析，编译效率更高。
Less 编译速度普遍比 Sass（尤其是 Dart Sass）慢，根本原因不在“语法多简单”，而在于执行引擎和编译器架构差异——Node.js 的 V8 引擎跑 Less 解析器，远不如 Dart Sass 的原生 Dart AOT 编译器高效。
Less 依赖 JavaScript 运行时，V8 解析 CSS-like 文本开销大
Less 是用 JavaScript 写的，所有解析、变量替换、mixin 展开、递归循环都运行在 Node.js 的 V8 引擎上。V8 虽快，但本质是为通用 JS 设计，不是为 CSS 预处理优化：
- 每次
@import都触发文件读取 + 字符串正则匹配 + AST 构建，无缓存复用逻辑（旧版 less-loader 尤其明显） - 递归 mixin（如模拟
@each）靠函数调用栈展开，V8 堆栈管理+作用域闭包创建成本高，深嵌套易卡顿 - 字符串插值（如
@width: `document.body.clientWidth`）需沙箱 eval，实际工程中禁用，但解析器仍要预留 JS 执行路径
Dart Sass 使用 AOT 编译，跳过解释执行环节
Dart Sass（当前官方推荐实现）用 Dart 编写，通过 dart2native 编译为原生二进制，启动即运行，没有 JS 解释/即时编译（JIT）延迟：
- 词法分析器和语法解析器是 hand-written（非生成式），针对 SCSS 语法规则高度定制，跳过通用 parser 通用性开销
- 变量查找走哈希表 + 作用域链，
$color访问是 O(1) 查表，Less 的@color在嵌套中需动态遍历作用域链 -
@use模块系统支持静态导入分析，编译前就能剔除未引用的 mixin/变量，Less 的@import全量合并后才开始处理
Webpack 中的 loader 配置会放大性能差距
真实项目里，编译速度差异常被构建配置放大，尤其在增量编译场景：
-
less-loader默认不开启javascriptEnabled: false，即使你没写 JS 插值，它仍保留 JS 沙箱初始化逻辑 -
sass-loader配合implementation: require('sass')（即 Dart Sass）可启用cache选项，复用前次 AST；Less 无等效 cache API - 当项目含大量
@import（如 Bootstrap Less），Less 每次都要重新 parse 所有被 import 文件；Dart Sass 的模块化让@use "bootstrap/scss/functions"只加载所需部分
别只看单文件编译耗时——大型项目中，Less 的慢体现在热更新响应滞后、CI 构建超时、IDE 实时预览卡顿。这些不是“语法不够快”，而是 JavaScript 运行时不适合做确定性、高频次的文本转换任务。Dart Sass 的二进制体积虽大，但换来的是稳定 sub-100ms 的单文件编译延迟，这对开发体验是实打实的差别。
