根本原因是Less编译器解析时机、单位处理和变量作用域不一致；裸除法须加括号或点除，calc()必须用~""转义插值，百分比需round()控精度，且所有计算值须统一变量源头与注入时机。
根本原因不是环境差异，而是 Less 编译器在不同构建阶段对运算的解析时机、单位处理和变量作用域不一致——尤其是裸除法、calc() 插值、百分比精度这三处，最容易导致 Windows 开发能过、Linux 构建失败，或 Vite 生产环境 CSS 与开发不匹配。
Less 裸除法（如 100px / 4）在不同环境输出不同
Less 4.x 彻底移除对未包裹除法的数学解析能力，但部分旧版 lessc 或某些构建工具缓存行为会让它“偶然成功”。Windows 下 Node.js 有时容忍语法松散，Linux 下更严格，直接原样输出 100px / 4 → 浏览器丢弃整条声明。
- 必须显式加括号：
(100px / 4)或使用点除：100px ./ 4（注意前后空格） -
line-height: 20px / 16px这类带单位除法必崩，改用line-height: (20px / 16px)或无单位比值line-height: 1.25 - 变量定义也受此影响：
@gap: 1rem / 2会变成字符串"1rem / 2"，后续所有引用失效
calc() 在开发/生产环境表现不一致
Vite 开发时走 HMR 管道，calc(100% - @gap) 可能被部分插件忽略；生产构建开启 css.extract: true 后，Less 会提前解析 - 符号，把 100vh - 80px 错算成 20vh —— 这不是浏览器问题，是编译期误算。
- 唯一可靠写法是转义字符串：
width: calc(~"100% - @{gap}"); -
@gap必须自带单位（如@gap: 20px;），不能靠拼接补：calc(~"100% - @{gap}px")是冗余且易错的 - 减号前后必须有空格：
calc(~"100% - @{gap}")✅，calc(~"100%-@{gap}")❌（浏览器静默忽略） - 避免嵌套：
@w: calc(~"100% - @{gap}"); margin: @w + 10px会失败，因为@w是字符串
百分比和四舍五入在不同平台渲染错位
Less 默认保留高精度小数，percentage(1/3) 输出 33.33333333333333%。Windows 和 Linux 下字体渲染、像素舍入策略不同，同一串浮点百分比在不同系统上可能被浏览器转成不同像素值，多个元素叠加就偏移。
立即学习“前端免费学习笔记（深入）”；
- 必须用
round()控制精度：width: round(percentage(1/3), 2);→33.33% - 不能对带单位值直接
round：round(33.333333%, 2)报错；安全写法是round(unit(percentage(1/3), %), 2) * 1% - 所有相关尺寸（列宽、间距、gap）必须从同一变量推导，比如统一用
@columns: 12;，再算percentage(4 / @columns)，而非混用手写33.33%和25%
Vite 生产构建中 Less 变量注入失效
modifyVars 只作用于预处理器阶段，但 Vite 生产构建的 CSS 提取流程可能绕过它：public 目录下的 .less 不处理、异步组件的 <style lang="less"> 在 chunk 中被独立编译、--mode staging 下 .env.staging 未透传 VITE_ENV 到 modifyVars，都会导致 if(@env = 'staging') 恒为 false。
- 确保
vite.config.ts中css.preprocessorOptions.less.modifyVars显式读取环境变量：{ env: process.env.VITE_ENV || 'development' } - 所有全局变量通过
additionalData注入，路径必须正确且文件非空，否则生产环境静默跳过 - 避免在
public/放 .less 文件——它不会走 Vite 构建链，modifyVars完全无效 - 异步组件样式若依赖主包变量，需手动在入口
main.ts中 import 对应变量文件，确保运行时可用
真正难的不是单个运算怎么写，而是保证所有参与计算的值——单位、精度、作用域、注入时机——在开发、测试、构建全流程中始终一致。任何一处松动，都会在某个环境里突然暴露。
