Less HMR 慢源于编译非原生、动态逻辑绕过模块系统、无法并行执行三重问题，导致延迟达1.2s+；替代方案为采用CSS自定义属性、UnoCSS或CSS Modules配合LightningCSS。
Less 编译本身会拖慢 HMR
Less 不是 Vite 原生支持的 CSS 预处理器，它依赖 less 包在运行时解析、编译，而 Vite 默认的 esbuild CSS 处理器不处理 Less。每次修改 .less 文件，Vite 必须调用 Node.js 版的 Less 解析器，走完整 AST 构建 → 变量计算 → 嵌套展开 → CSS 输出流程，比原生 CSS 或 LightningCSS 慢 3–5 倍。
尤其当 Less 文件里用了大量 @import、.mixin()、& 嵌套或 @extend 时，AST 重建开销剧增，HMR 延迟从 200ms 直接跳到 1.2s+。
- Less 编译全程在主线程执行，无法并行，阻塞 HMR 流水线
- Vite 的
css.transformer: 'lightningcss'对 Less 文件完全无效——LightningCSS 不支持 Less 语法 - PostCSS 插件（如
postcss-preset-env）叠加在 Less 编译后，进一步延长链路
Less 中动态行为绕过模块系统
Less 支持运行时变量注入（如 @primary-color: @theme-color）、条件混合（.when(@debug = true)），这些逻辑让 Vite 无法静态分析依赖关系。一旦变量值来自 JS 运行时或环境配置，Vite 就无法确定哪些文件真正受影响，只能退化为全模块链重载。
-
@import路径含变量（如@import "@{base}/mixins.less"）→ Vite 无法解析导入目标，跳过依赖追踪 - 使用
less.modifyVars在 JS 中动态改主题色 → 修改不触发任何 HMR，样式“卡住”不动 - 通过
document.createElement('style')注入编译后的 Less 字符串 → 完全脱离 Vite 模块系统，HMR 彻底失效
替代方案：用 UnoCSS 或原生 CSS Modules 替代 Less
Less 的 HMR 慢本质是“编译 + 动态 + 非标准”三重负担。真正提速不是调参数，而是换路径：
立即学习“前端免费学习笔记（深入）”；
- 把全局变量抽成 CSS 自定义属性（
:root { --primary: #3498db; }），用var(--primary)替代 Less 变量，浏览器原生支持，零编译 - 用
unocss替代less：原子化类名按需生成，修改 class 名即生效，HMR 响应在 50ms 内 - 启用
css.modules+lightningcss：Vite v6.3.2+ 支持css.lightningcss.cssModules.auto: true，.module.css 文件可享受极速 HMR 和作用域隔离 - 若必须用 Less，至少禁用嵌套和
@extend，改用扁平规则 +composes组合（配合 CSS Modules）
配置层面能做的有限补救
即使保留 Less，也能小幅缓解，但无法根治：
- 确保
css.devSourcemap: true—— 否则连局部规则定位都失效，整文件重载 - 在
optimizeDeps.include中加入'less'，避免每次启动重复加载 Less 解析器 - 用
server.watch.ignored排除**/node_modules/**和构建产物目录，防止 Less 变更触发无关监听抖动 - 不要在
less-loader或自定义插件里加额外的 PostCSS 处理——每多一层转换，HMR 就多一次等待
Less 的 HMR 慢不是配置没调好，而是它的设计与 Vite 的 ESM 按需编译模型天然冲突。越想“优化 Less”，越容易陷入编译链加长、依赖图爆炸的陷阱。真正省时间的做法，是让样式逻辑回归浏览器能力边界——CSS 自定义属性、原子化、模块化，而不是靠预处理器扛全部职责。
