根本原因是生产环境css提取、变量注入时机与样式加载顺序三者叠加导致less编译结果与运行时css不匹配：css.extract:true破坏按需编译，modifyvars未穿透全部阶段，异步组件样式加载顺序失控，系统路径/bom/换行符差异进一步放大不一致。
根本原因不是 Less 本身出错，而是构建环境（生产）和本地环境（开发）在 CSS 提取、变量注入时机、样式加载顺序三者叠加后，导致最终应用的 CSS 与 Less 编译时预期不一致。
css.extract: true 强制全量提取破坏按需编译链路
Vite 开发时默认把 <style lang="less"></style> 编译后内联进 JS，通过 injectStyle 动态插入；生产环境开启 css.extract: true 后，所有 Less 文件被统一收集、合并、压缩为独立 .css 文件。这带来两个隐性问题：
- 原本按组件模块触发的编译（如只编译
Button.vue中的样式）变成全量扫描，@import关系可能被提前解析或重复解析 -
modifyVars注入的变量（如@env: 'production'）在提取阶段被固化一次，但若多个入口或异步 chunk 共享同一变量定义，可能因注入时机不一致导致分支逻辑错位
modifyVars 未穿透到所有构建阶段
vite.config.ts 中的 css.preprocessorOptions.less.modifyVars 只影响预处理器阶段，但部分样式会绕过它：
- 放在
public/下的.less文件不会被 Vite 处理，直接复制——它压根不走modifyVars - 通过
additionalData注入的全局变量（如@import "vars.less";），若路径错误或内容含语法错误，开发环境报错明显，生产环境可能静默跳过，导致变量 fallback 为默认值 - 构建时用了
--mode staging，但.env.staging里没透传VITE_ENV到modifyVars，Less 里if(@env = 'staging')就永远为false
异步组件样式加载顺序失控
Vue/React 中用 defineAsyncComponent 或 lazy() 加载的组件，其 <style lang="less"></style> 在生产环境会被打到异步 chunk 对应的 CSS 文件中，但 HTML 中的 <link> 插入顺序无法保证早于主 CSS：
- 浏览器并行加载多个
.css文件，无明确优先级声明时，按网络响应先后应用样式 - 若主包 CSS 包含重置规则（如
* { box-sizing: border-box; }），而异步 CSS 先加载完成，就会短暂出现布局错乱 - Vite 不会自动给异步 chunk 的 CSS 添加
rel="preload"或media="print" onload="this.media='all'"这类控制手段
Windows 与 Linux 路径/BOM/换行符差异放大环境不一致
这些系统级差异在开发时往往被掩盖，一到 CI/CD 构建就暴露：
-
@import "mixins\variables.less";（反斜杠）在 Windows 编辑器里看着正常，但 Less 解析器把它当字面量字符串，找不到文件；必须统一用正斜杠：@import "mixins/variables.less"; - Windows 记事本保存的
.less文件常带 UTF-8 BOM（EF BB BF），Linux 下lessc4.x+ 会直接报parse error: unrecognised input；VSCode 中右下角编码选 “Save with Encoding → UTF-8” 清除 BOM - Windows 默认 CRLF 换行符，Linux/macOS 用 LF；某些插件（如
less-plugin-clean-css）对换行敏感，会导致输出 CSS 的空行、缩进甚至属性顺序微调
真正难调试的点在于：这些机制彼此不耦合，但一旦叠加，错误现象（比如按钮颜色突然变蓝、间距错乱、@primary-color 原样输出）很难归因到某一个环节。你得逐层确认变量是否注入成功、CSS 是否按预期拆分、异步样式是否晚于重置规则加载、以及构建机上的文件编码是否干净——漏掉任何一环，都会让“本地好好的”变成上线后的线上事故。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
