Less所有数学运算在编译期完成，单位必须严格匹配，否则报错或字符串拼接；unit()是唯一安全的单位处理函数，复合运算须加括号并统一单位。
Less 本身不支持运行时数学运算，所有计算都在编译期完成，且单位处理极其严格——写错一个单位，结果就变成字符串拼接或编译报错。
Less 的加减乘除只能用于同单位或无单位数值
Less 的 +、-、*、/ 不是 JavaScript 那种动态运算，而是静态类型检查下的编译期求值。单位必须兼容，否则直接报错或返回非法值。
-
10px + 5px→15px（合法） -
10px + 5em→ 编译失败：Operation on an invalid type -
10px * 2→20px（数字无单位，可参与乘除） -
10px / 2px→5（单位相消，结果无单位） -
10px / 2em→ 报错，单位不可约分
Unit() 函数是唯一可控的单位剥离/重赋手段
想把 2.5rem 转成纯数字参与计算？不能靠 ~"2.5rem" 或字符串操作——那只是欺骗编译器，后续仍无法运算。unit() 是 Less 提供的正规解法：
@base: 1.5rem; @ratio: 2.5; <p>// 错误：unit(@base) <em> @ratio → 会报错，因为 unit() 返回的是带单位的值 // 正确：先用 unit() 剥离单位，再用单位重赋 @val: unit(@base, px); // 若 @base 是 1.5rem，这步会失败（单位不匹配） // 所以更稳妥的是：显式转为相同基准单位再算 @px-base: 24px; // 假设 1rem = 24px @computed: (@px-base </em> @ratio) / 10; // → 6px
关键点：
立即学习“前端免费学习笔记（深入）”；
-
unit(@value, px)只在@value原本就是px单位时才安全；其他单位需手动换算 - 没有内置
remToPx()或emToPercent()，必须靠设计系统约定（如@rem-base: 16px）自行建模 - 避免在变量定义里嵌套多层
unit()，容易触发 Less 解析歧义
复杂表达式要拆步、加括号、验单位
写 (@a + @b) * @c / @d 看似自然，但 Less 对运算优先级和单位传播非常敏感。比如：
@gap: 12px; @scale: 1.2; @padding: (@gap * @scale) + 2px; // → 16.4px ✅ @margin: @gap * @scale + 2px; // → 14.4px2px ❌（+ 被当字符串连接！）
原因：+ 在无括号时优先级低于 *，但单位处理逻辑会让 @gap * @scale 得到 14.4px，而 + 2px 因左侧有单位、右侧也有单位，却未被识别为同单位加法（Less 认为这是两个独立 token），最终退化为字符串拼接。
- 永远对复合运算加括号：
(@gap * @scale) + 2px - 避免混用单位：不要在同一个表达式里出现
px和rem，除非你已提前统一换算 - 用
//注释单位预期：@height: (2 * @line-height) + 4px; // => px
单位不是装饰，是 Less 类型系统的硬约束。写错一个 px 写成 em，或漏掉括号，编译器不会警告，只会静默产出错误值——而这个值往往在 UI 上表现为“莫名偏移几像素”，极难定位。
