Less实现CSS网格系统：循环生成栅格布局

本文深入剖析了在Less中实现CSS网格系统时的四大核心陷阱：一是`.make-grid-columns()`等mixin必须显式调用且严格依赖预定义的`@grid-columns`变量，否则编译后零输出；二是所谓“循环”实为递归mixin，需精准传递参数、设置终止条件并正确使用字符串插值，否则极易陷入无限递归或全生成相同类名；三是列宽计算绝非简单比例换算，必须显式扣除gutter占比或借助`calc()`交由浏览器运行时处理，避免像素偏差；四是Less无自动剪枝机制，盲目循环生成全量栅格类及变体将显著膨胀CSS体积、拖慢首屏渲染——真正高效的方案是按需生成、分离关注点，并在复杂响应式场景中适时让位于原生CSS Grid能力。

Less 里用 .make-grid-columns() 为什么没效果

因为 Less 的循环不是运行时执行，而是编译时展开；.make-grid-columns() 这类经典 Bootstrap 风格的 mixin 必须配合 @grid-columns 和显式调用才能生效，光定义不调用等于没写。

常见错误现象：div.col-3 没宽度、浏览器里查不到对应 CSS 规则、编译后 CSS 文件里完全没生成栅格类。

• 确认已定义 @grid-columns: 12;（或你需要的列数），且在 mixin 前声明
• 必须显式调用 .make-grid-columns();，不能只靠 @import 引入就自动触发
• 如果用的是自定义变量名（比如 @cols），mixin 内部也得用相同变量，否则取不到值

用 for 循环生成 .col-{n} 类时，为什么 n 全是 12

Less 没有原生 for 语句，所谓“循环”本质是递归 mixin + 保护条件；如果忘了递减参数或终止条件写错，就会无限递归或提前退出，导致所有生成的类都用了初始值。

典型错误：写成 .make-col(12) when (@i > 0) { ... .make-col(@i - 1); }，但没定义 @i 初始值，或者把 @i 写成全局变量被多次覆盖。

• 递归 mixin 必须带参数传递，如 .make-col(@n)，每次调用传新值，别依赖外部变量
• 终止条件要严格，推荐用 when (@n > 0) 而非 when (@n = 0)，避免整数精度或负数漏判
• 生成选择器时，用字符串插值 .col-@{n}，不是 .col-@n（后者会被当变量名解析，报错或为空）

.col-6 宽度算出来不对，和预期差几个像素

Less 计算依赖单位一致性。如果 @grid-gutter-width 是 30px，而你用 percentage(6 / @grid-columns) 算宽，却没扣掉 gutter 占比，结果就会偏大。

实际栅格宽度 = 列占比 × (100% − 总 gutter 占比)，不是简单列数除总列数。

• 先统一单位：gutter 推荐用 rem 或 px，别混用 em 和 %
• 计算列宽时显式减去 gutter 影响，例如：width: percentage((6 / @grid-columns) - (@grid-gutter-width * 6 / 2 / 100%));（假设两列间一个 gutter）
• 用 calc() 留给浏览器运行时计算更稳妥，Less 只负责拼字符串：width: calc(~"(@{col-width} - @{gutter})");

编译后 CSS 体积暴涨，.col-1 到 .col-12 每个还带 hover/focus 变体

Less 不会自动剪枝——你让循环生成 12 个类，它就真生成 12 个；如果每个类再套一层伪类或媒体查询，数量直接翻几倍。这不是 bug，是设计如此。

性能影响明显：未压缩 CSS 多出 2–3KB，gzip 后仍多 0.5KB+，对首屏渲染有可测延迟。

• 只生成真实需要的断点类，比如移动端只用 .col-12，就别循环 1–12 全生成
• 伪类样式用单独 mixin 控制，不要嵌在列循环里，例如 .col-hover() { &:hover { ... } } 按需调用
• 开发期用 // 注释掉不用的循环分支，比条件编译更直观、更少出错

最麻烦的其实是响应式栅格里的嵌套计算：同一套列数，在不同断点下要重新算 gutter 分摊和 minmax，这时候靠纯 Less 循环容易失控。真要复杂布局，不如把核心逻辑交给 CSS Grid 自身，Less 只管 class 名称组织。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。