Less编译时错误将calc()当作数学表达式计算，导致报错或输出非法值；必须用~"calc(100% - @{gap})"转义并确保变量带单位、空格合规。
Less 编译后 calc() 出现异常，根本不是浏览器问题，而是 Less 在编译期错误地把 calc() 当作自己的数学表达式去计算了——它压根没打算把 calc() 原样交给浏览器。
calc(100% - @gap) 直接报错或输出错值
Less 会尝试执行 100% - @gap 这个减法：如果 @gap 是 24px，单位不匹配（% vs px），Less 报 Operation on different types；如果 @gap 是未定义变量，报 Variable @gap is undefined；更糟的是，某些旧版 Less 会强行换算并输出 calc(76%) 这种非法值。
实操建议：
- 绝对不要写
calc(100% - @gap)或calc(@a + @b) - 必须用转义字符串包裹整个表达式：
width: calc(~"100% - @{gap}") -
@gap必须带单位（如@gap: 24px），否则插值后变成calc(100% - 24)，浏览器直接丢弃整条声明
Firefox 下 calc() 看似“不生效”，其实是被静默丢弃
Firefox 对 calc() 语法零宽容。Less 编译时若生成了 calc(100%-@{gap})（减号后没空格），最终 CSS 就是 calc(100%-24px)，Firefox 直接跳过该样式，DevTools 的 computed 面板里完全不显示，看起来像“没生效”。
立即学习“前端免费学习笔记（深入）”；
实操建议：
- 确保转义字符串内空格合规：
~"calc(100% - @{gap})"，不是~"calc(100%-@{gap})" - 调试时可临时加一条
.debug { content: "@{final-calc}"; }，把编译结果打出来肉眼核对 - 别依赖浏览器兼容性兜底——Firefox 不报错，只沉默失效
带乘除或嵌套的复杂 calc 表达式容易单位错乱
比如 calc((100vw - 2 * @gutter - 3 * @item-width) / 3)，Less 不会自动给中间结果补单位。若 @gutter: 16（漏写 px），2 * @gutter 得到纯数字 32，最终输出 calc((100vw - 32 - 600) / 3)，浏览器无法解析。
实操建议：
- 所有参与 calc 的变量必须显式带单位：
@gutter: 16px、@item-width: 200px - 避免在
~""内写运算，只做插值；复杂逻辑拆成中间变量：@total-width: (100vw - 2 * @gutter - 3 * @item-width); width: calc(~"@{total-width} / 3"); - 用
unit(@val, 'px')强制统一单位，防止变量来源不可控
真正容易被忽略的是：哪怕你只在某个 mixin 里写了一次没转义的 calc(@h - 1px)，它也可能在深层嵌套展开时被悄悄计算，导致上线后某处布局突然偏移——这种 bug 不会在编译时报错，也不会在本地必现，但一定会在某个分辨率下露馅。
