<p>Less加减法必须单位一致，因编译期静态类型检查禁止跨单位运算；%与px混用如100% - 20px会报错，需统一为无单位小数、换算为px或改用calc()字符串插值。</p>
Less加减法为什么必须单位一致
Less在编译期做静态类型检查，+和-操作符不支持跨单位运算——这不是bug，是设计约束。写@width: 100% - 20px会直接报错Operation on an invalid type，因为%和px无法对齐。
常见错误现象：
- 以为
100% - 20px能像CSScalc()那样运行时计算，结果编译就卡住 - 把
@gutter: 20px直接用于100% - @gutter，忽略单位不可混用规则
正确做法：
- 统一用无单位小数表示比例：比如
@gutter-ratio: 0.01666;，再算((1 - @gutter-ratio * 2) / 3) * 100% - 若gutter是固定像素且容器宽度已知（如
@container-width: 1200px），全换算成px：(@container-width - @gutter * 2) / 3 - 必须交由浏览器运行时处理的场景，改用
calc()并配合字符串插值：width: calc(~"100% - @{gutter}");
unit()函数不是单位换算，只是单位剥离或强加
unit()不理解“10px等于多少em”，它只做两件事：剥离单位返回纯数字，或给数字强加指定单位。比如unit(10px, em)不会变成0.625em，而是报错；但unit(10, px)会输出10px。
立即学习“前端免费学习笔记（深入）”；
使用场景：
- 把带单位变量转为数字参与条件判断，如
when (unit(@size, px) > 768) - 确保输出单位可控，避免
@gap: 2rem * 1.5在mixin里传参失败（因未求值表达式节点不被接受） - 配合
round()控制精度：round(unit(@val, px) / 16, 2)→ 转为rem前先算好数值
容易踩的坑：
- 误用
unit(@val, em)期望自动换算，实际只在@val本身是纯数字时才安全 - 没提前用
ispixel()校验就调unit(@val, px)，导致编译失败
除法/在Less里可能被当注释处理
默认math模式下，/在某些上下文会被解析为CSS注释分隔符。比如写font: 14px/20px，Less可能把/20px当成注释丢掉，输出font: 14px;，静默失效。
解决方案：
- 开启Strict Math（
math: strict），强制所有/都按数学运算处理 - 统一改用
math.div()函数：math.div(100, 3)比100 / 3更可靠 - 涉及百分比计算时，用
percentage()替代除法：percentage(1/3)→33.333333%，再用round()收口：percentage(1/3, 2)→33.33%
性能影响：
-
math.div()和percentage()都是编译期函数，无运行时开销 - 但
percentage(1/7, 2)比100% / 7更明确，避免小数位污染CSS输出
响应式计算别在Less里硬套calc()链
Less不解析calc()内部表达式，@gap: 20px; width: calc(100% - @gap);会报错——calc()只认原生CSS语法，不认Less变量。
正确路径：
- 先用Less算出数值，再拼进
calc()：@gap-px: 20px; width: calc(100% - @{gap-px}); - 或用字符串插值强制解析：
calc((~"100% - @{gap-px}") / 4)，但要注意括号层级和空格 - 更推荐方案：关键尺寸用Less编译期算死，复杂流体逻辑交给
calc()原生处理，两者职责分离
最容易被忽略的一点：
所有单位混合计算的“合理性”都在编译期验证，一旦漏掉unit()校验、或没设math: strict，错误往往藏在某次构建里，直到上线后布局错位才暴露——它不报错，只是输出了你没意识到的字符串拼接结果。
