Less环境变量需在编译时通过--modify-var或构建工具modifyVars传入，无法运行时切换；@import不支持条件语句；变量覆盖须确保作用域统一且命名用下划线；多入口需分别配置。
Less变量怎么在不同环境里自动换值
不能靠运行时切换，Less是编译时处理的，@env 这种变量写死在文件里就固定了。真正能动态注入的只有编译阶段传入的参数——比如通过 lessc 的 --modify-var 或构建工具（Webpack/Vite）插件传入的 modifyVars。
- 开发时用
lessc --modify-var="env='dev'" main.less，生产时换成--modify-var="env='prod'" - Webpack 的
less-loader配置里写modifyVars: { env: process.env.NODE_ENV === 'production' ? "'prod'" : "'dev'" }，注意字符串要套单引号 - Vite 用户得用
lessOptions.modifyVars，且必须确保 Vite 启动时环境变量已加载（.env文件里的VITE_ENV不能直接用，得靠插件或启动脚本透传）
为什么@import条件引入会失效
Less 不支持 @import 里写逻辑判断，像 @import (when (@env = 'dev')) 'dev-variables.less'; 是非法语法，编译直接报错 Unrecognised input。
- 正确做法是把所有变量定义写进一个入口文件，用
--modify-var覆盖关键值，再统一@import公共样式 - 想按环境分文件？只能靠构建工具先拼好路径，比如 Webpack 中用
less-loader的additionalData注入一段@import，内容由 JS 动态生成 - 别在 Less 里写
if或三元，它没这能力，硬写只会卡在编译第一步
@primary-color 这类变量被覆盖后为啥没生效
Less 变量作用域是“后声明覆盖前声明”，但前提是它们在同一个编译上下文里。如果 theme.less 里定义了 @primary-color: #1890ff;，而你在命令行用 --modify-var="primary-color=#722ed1"，它确实会覆盖——但前提是 theme.less 是被 main.less @import 进来的，且 main.less 是你传给 lessc 的入口文件。
- 常见坑：把
--modify-var传给了子文件（比如只编译theme.less），那它根本没机会被覆盖 - 另一个坑：变量名带连字符（如
@bg-color）传参时写成--modify-var="bg-color=#fff"，Less 会解析失败，必须写成--modify-var="bg_color=#fff"（下划线替代） - 调试方法：加
--verbose看编译日志，确认变量是否真被修改，或者临时在样式末尾加body::before { content: "@{primary-color}"; }直接看输出值
Webpack打包时modifyVars不生效的典型场景
不是配置写了就管用。Vite 和 Webpack 对 less-loader 的调用时机、配置合并逻辑完全不同，尤其涉及 CSS 提取（MiniCssExtractPlugin）时容易漏掉 loader 配置。
立即学习“前端免费学习笔记（深入）”；
- Webpack 5+ 必须确保
less-loader在css-loader之前，且modifyVars放在less-loader的options里，不是整个 rule 的 options - 用了
MiniCssExtractPlugin？得同时给development和production两套 rule 都配modifyVars，否则热更新时还是旧值 - 如果项目有多个 Less 入口（比如组件库单独编译），每个入口都要单独传
modifyVars，全局配置不会透传
Less 环境变量的本质是编译参数，不是运行时开关。所有“动态”都发生在构建那一刻，一旦 CSS 输出，就再无回旋余地。最容易被忽略的是变量名转义规则和多入口场景下的配置遗漏——这两个点卡住的人最多。
