在处理 Less 多列布局的宽度计算时，有一个常见却容易被忽视的陷阱，今天我们来系统梳理并深入解析。
使用 percentage() 函数计算列宽，避免直接写 100% / @n
很多开发者图省事，直接写 width: 100% / @n，觉得简洁易懂，对吧？但旧版编译器遇到这种写法时，可能会原封不动地输出 width: 100% / 3，浏览器解析时直接报错，无法识别。更稳妥的做法是调用 Less 内置的 percentage() 函数：width: percentage(1 / @n)。该函数会强制在编译阶段计算出带百分号单位的字符串，例如当 @n: 4 时，输出结果为 25%，干净利落，不会产生令人困惑的截断。
这里有两个细节值得留意。第一，必须写成 percentage(1 / @n)，而不是 percentage(1) / @n——后者实际上执行的是除法运算，函数调用的逻辑就变了。第二，如果列数来自外部变量，比如栅格系统的总列数 @grid-columns: 24，那宽度公式也要相应调整：flex-basis: percentage(@span / @grid-columns)。否则，像 .col-3-of-24 这类类名计算出的值就会与实际不符。
间隙参与计算时，先用 unit() 统一单位再运算
列与列之间通常需要留间隙，比如 @gap: 1rem。要计算净宽度，就得减去间隙的总和：(100% - (@columns - 1) * @gap) / @columns。问题在于，@gap 带有单位，而 @columns 是纯数字，Less 不允许跨单位做除法。如果直接写 width: (100% - (@n - 1) * @gap) / @n，编译就会失败。
别急，正确做法分两步走：先利用 unit() 函数将间隙转为像素或百分比等统一单位，再参与运算。例如，定义 @gap-px: unit(@gap, px)，然后写 width: (100% - (@n - 1) * @gap-px) / @n。如果使用 rem，要确保根字号固定，否则 1rem 在不同设备上像素值会浮动，布局精度也就难以保证。
响应式断点中必须重新计算列宽，不能复用默认值
假设你在 @sm: 576px 这个断点设置了 @cols: 3，到了 @md: 768px 想改为 @cols: 4，那么所有对应类（比如 .col-md-2）的宽度就不能再沿用 percentage(1 / 3) 了，必须重新计算为 percentage(2 / 4)。一个常见的错误是只修改了列数变量，却忘记在媒体查询块中调用新的宽度计算逻辑。
推荐封装一个带校验的 mixin 来辅助：.media-up(@size) when (isunit(@size, px)) { @media (min-width: @size) { @content; } }。调用时写上 .media-up(@md) { width: percentage(1 / 4); }。注意，断点变量定义时必须带上单位：@md: 768px;，引用时用 @{md}，否则 @media (min-width: @md) 会输出无效的 @media (min-width: 768)，导致断点失效。
别指望 calc() 在 Less 中完成动态运算
再说一个容易踩坑的点：指望 calc() 在 Less 里做动态运算，基本上是徒劳的。例如写 width: calc(100% / @n)，Less 会在编译期尝试执行这个除法，但 calc() 是浏览器运行时才计算的函数，两者阶段完全错位。更糟糕的是，某些版本会把 @n 当成字符串拼接进去，生成 calc(100% / 3)，虽然能运行，但小数截断可能导致12列加起来不足100%，最后一列直接掉行。
如果确实需要保留 calc()（例如要兼容旧浏览器，或者配合 JS 动态调整），必须使用 Less 的转义语法：width: ~"calc(100% / @{n})"。但心里要有数：这种方法只适用于固定列数的场景。一旦列数需要随容器宽度实时变化，还是交给 column-count 或 grid-template-columns: repeat(auto-fit, minmax(...)) 更靠谱——Less 的数学函数管不了运行时的事情。
最后重申一个容易被忽略的核心要点：所有这些计算在编译完成时就固化成 CSS 了。修改 @cols 后必须重新编译；而“列数随视口宽度连续变化”这类需求，Less 本身根本无法处理。