Less 的 unit() 函数不进行单位换算，仅剥离或强加单位；正确换算需依赖基准值（如 @base-font-size），配合除法与 unit() 手动计算；math.div() 比 / 更安全，避免注释歧义；percentage() 和 round() 控制精度；所有运算须同单位，响应式逻辑应交由 calc() 处理。
Less 中 unit() 函数为什么算不对？
因为 unit() 不做数值转换，只剥离或强加单位——它不理解“10px ÷ 2”是 5，更不理解“10px + 1em”需要先转换单位。常见错误是以为 unit(10px, em) 能自动换算，结果输出 10em，完全失真。
- 真正做单位换算得靠已知基准值：比如定义
@base-font-size: 16px;，再用unit(10px / @base-font-size, em)得到0.625em -
unit()的第二个参数如果为空（unit(10px)），返回纯数字10；填了单位则强制套上，不管是否合理 - 所有运算必须在同单位下进行，Less 不会帮你做 px/em/rem 间的 runtime 转换——那是浏览器做的事，不是编译器的职责
用 percentage() 和 round() 控制响应式比例精度
写流体布局时，直接写 width: 1/3 * 100% 会得到无限循环小数（如 33.333333333333336%），CSS 渲染虽能接受，但可读性差、diff 难追踪。
- 改用
percentage(1/3)→33.333333%（默认 4 位小数） - 需要整数就套一层
round(percentage(1/3))→33%，但注意：round(33.5%)会报错，百分比值不能带单位进round()，得写成round(percentage(1/3)) + % - 小数位数可指定：
percentage(1/7, 2)→14.29%，避免无意义的长小数污染编译后 CSS
为什么 math.div() 比 / 更安全？
Less 默认除法 / 在某些上下文中会被当作 CSS 注释分隔符（比如 font: 14px/20px），导致编译异常或静默失效。而 math.div() 是明确的函数调用，无歧义。
- 开启 math 模式（Less v4+）后，
/才按数学运算处理，但旧项目或未配math: always时仍危险 -
math.div(100%, 12)稳定返回8.333333%，且支持混合单位：math.div(1rem, 16px)→1（前提是1rem = 16px） - 注意：
math.div()要求两个参数都为数字或同单位值，math.div(10px, 2em)会报错，不是自动换算
避免在计算中混用 @media 变量和运行时单位
Less 是编译时处理，所有计算都在 CSS 输出前完成。这意味着你无法用 @screen-sm 这类断点变量去驱动 unit() 或 percentage() 的逻辑分支——它们只是静态值，不是 JS 里的条件执行。
立即学习“前端免费学习笔记（深入）”；
- 常见错误：写
.box { width: if(@screen-sm > 768px, 50%, 100%); }——if()只能判断数值，@screen-sm若定义为768px，比较768px > 768px会报错，因为单位不能直接比大小 - 正确做法：统一用无单位数存断点基准，如
@screen-sm: 768;，再配合unit(@screen-sm, px)输出 - 真正需要运行时计算的地方（如视口单位换算），应该交给
calc()，而不是塞进 Less：例如width: calc((100vw - @{container-width}) / 2);
单位换算的本质是「编译时确定关系」，不是「运行时推导」。最容易被忽略的是：你写的每个 unit()、percentage()，背后都依赖一个你手动维护的隐含换算基准——漏掉这个，所有精度优化都白搭。
