less 4.x 升级后裸除法（如100px / 4）编译失败，因其移除裸除法解析能力，必须写成(100px / 4)或100px ./ 4；calc()插值需用~"100% - @{gap}"转义；@import纯css文件须显式声明@import (css)；math: "always"配置无效，仅math: 1或2生效。
Less 4.x 升级后旧语法报错，不是编译器“变严格”了，而是解析器彻底重写 + 两个关键开关默认开启：strictMath 和 strictUnits。老项目里大量存在的裸除法、calc() 插值、单位混用等写法，会在编译期直接中断，不是警告，是硬性报错。
为什么 100px / 4 突然编译失败？
Less 4.x 移除了对裸除法（即未加括号的 /）的数学解析能力。它不再尝试计算，而是原样输出 100px / 4 到 CSS 中——浏览器视其为非法声明，静默丢弃，DevTools 里该行显示为灰色划掉。
- 必须写成
(100px / 4)或100px ./ 4（注意./前后必须有空格） -
line-height: 20px / 16px同样失效，应改用line-height: (20px / 16px)或更稳妥的无单位值line-height: 1.25 - 变量定义也受影响：
@gap: 1rem / 2不再生成数值，而是字符串"1rem / 2"，后续所有引用都崩
为什么 calc(100% - @gap) 直接报 ParseError？
calc() 是浏览器运行时函数，Less 编译期不识别其内部语法；但新版又把整个表达式当作数学运算去解析，导致冲突。
-
calc(100% - @gap)会被 Less 当作减法运算，而@gap若含单位或未定义，立刻报错 - 正确写法是用波浪号转义：
width: calc(~"100% - @{gap}")，其中@{gap}插值，其余字符串原样保留 - 切勿把
calc()塞进运算链：@w: calc(~"100% - @{gap}"); margin: @w + 10px——@w是字符串，加法必然失败
为什么 @import "reset.css" 突然不生效甚至报错？
Less 4.x 默认把所有 @import 当作 Less 源码处理。遇到纯 CSS 文件（如 reset.css），会尝试解析其中的 html { margin: 0; } 这类语句，结果因语法不兼容直接抛 ParseError。
- 唯一安全写法是显式声明：
@import (css) "reset.css" - 该语句必须放在主入口文件最顶部，且路径需能被构建工具定位（推荐用
@import (css) "~normalize.css/normalize.css"这类带别名的写法） - 如果用了第三方 UI 库（如 antd），其内部
@import链若没加(css)，也会在升级后集体炸开
为什么配置 math: "always" 完全没用？
Less 4.x 根本不认 math: "always" 或 math: "parens" 这类字符串配置——它们是旧版文档残留的错误信息，会被静默忽略，最终走默认的 math: 2（严格模式）。
- 真正有效的只有整数：
math: 1（兼容模式，允许裸除法）或math: 2（默认，强制括号） - Webpack 用户必须写在
less-loader的options里：{ loader: 'less-loader', options: { math: 1 } } - Vite 用户要嵌套在
css.preprocessorOptions.less下，漏一级就失效 - VS Code 的 Easy Less 插件不读这些配置，所以插件预览仍报错，不代表构建真失败
最易被忽略的点：表面编译通过 ≠ 样式正确。比如 1em * 2 在 Less 4.x 返回 2em（旧版是 2），而 10px + 1rem 直接报错而非静默转换单位——这些不会打断构建，但会让按钮尺寸、断点间距悄悄偏移。升级后务必人工抽检 DOM 的 computed 样式，尤其查清每个 @spacing-sm 背后是否还绑着隐式单位转换。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
