less仅支持编译期静态计算，无法处理响应视口、读取css变量或模拟minmax()等运行时逻辑；所有运算需单位匹配，函数只接受纯数字，calc()内变量不被解析，动态逻辑应交由css/js处理。
Less 无法用内置数学函数处理“复杂布局计算”中的运行时动态逻辑，比如响应视口变化、读取 CSS 自定义属性、或模拟 minmax() 行为。它只做编译期静态计算，所有结果在构建时就固定了。
Less 的 + - * / 只能做单位安全的静态运算
加减乘除不是 JS 式计算，而是带单位检查的编译期求值。单位不匹配直接报错：Operation on an invalid type；单位混用（如 1rem + 12px）不自动转换，也不会 fallback 成字符串拼接——它根本过不了编译。
- 同单位加减才合法：
@gap: 16px; margin: @gap + 4px;→20px - 乘法只允许数字作右操作数：
@size: 12px; width: @size * 1.5;→18px，但@size * 1em报错 - 除法必须括号包裹，否则可能被误认为 CSS 除号：
font: 14px/1.6是字体简写，不是运算；要算比例得写width: (100% / 3); - 单位传播规则：结果以**最左侧带单位的操作数**为准，
10em / 2→5em，10 / 2em→ 报错
percentage()、round() 等函数只吃纯数字，不认带单位值
percentage()、floor()、ceil() 这些函数签名严格限定为 number 类型。传入 100%/12 或 24px/16 会失败，因为前者是带单位表达式，后者除法结果虽为数字但中间过程触发单位冲突。
- 正确用法：
@cols: 12; .col-3 { width: percentage(3 / @cols); }✅ - 错误写法：
width: percentage(100% / @cols);❌（100%是带单位值） - 想从
rem入手？先靠设计系统约定统一基准：@rem-base: 16px; @val: unit(1.5rem, px) / @rem-base;，再喂给percentage() - 浮点误差常见于链式除法：
round((@a / @b / @c), 2)比round(@a / (@b * @c), 2)更易失精度，优先合并分母
calc() 在 Less 里只是字符串，变量不会被代入
写 width: calc(100% - @gap * 2); 不会生效。Less 遇到 calc() 就停止解析内部内容，原样输出，@gap 不会被替换。真要拼接，得用转义+插值：width: ~"calc(100% - @{gap-2x})";，且 @gap-2x 必须是已计算好的带单位值。
- 推荐路径：用 Less 先算好静态部分，浏览器 runtime 处理动态部分。例如列宽用
@{col-width}，间隙用calc()单独控制 - 不要试图在 Less 里“模拟”
fit-content()或minmax(auto, 1fr)—— 这些是布局引擎行为，Less 生成不了等效逻辑 - 媒体查询里的运算可以，但单位仍受限：
@media (max-width: (@breakpoint-md * 1.2)) { ... }合法，前提是@breakpoint-md是纯数字或同单位值 - 容易漏掉的是：插值
@{var}只在~""内有效，写成"calc(100% - @gap)"会把@gap当字面量输出
真正该交给 Less 做的，只有三类事
一是固定比例生成，比如栅格系统的 .col-4 类对应 width: 33.333%；二是主题变量衍生，比如 @primary-lighten: lighten(@primary, 10%);；三是基于设计系统约束的预计算，比如所有间距都是 @space-base 的整数倍。凡是需要响应屏幕尺寸、容器大小、用户交互或 CSS 自定义属性的，都得交给 CSS 本身或 JS。
最常被忽略的点是：Less 编译后 CSS 里不会留下任何计算痕迹，所有结果都是硬编码值。这意味着你无法通过 DevTools 查看“这个宽度是怎么算出来的”，调试只能回溯 Less 源码——所以每一步运算后建议加注释，或用临时 // debug: @{val} 辅助验证。
