根本原因是percentage()函数小数精度问题导致累加超100%，应使用round(percentage(1/@grid-columns),4)统一计算单列宽；断点与列数联动需用映射表@grid-breakpoints配合.each()遍历，并为各断点设独立列数变量；calc()中Less变量必须带单位，建议封装.gutter-calc()函数校验。
Less里用.make-col这类循环生成栅格类，为什么编译后宽度不对？
根本原因不是循环写错了，而是percentage()函数对小数运算不友好——比如percentage(1/12)会算成8.333333333333334%，而浏览器渲染时多个这种值累加可能突破100%，导致换行或错位。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 改用
round(percentage(1/12), 4)强制保留4位小数，再喂给width - 所有栅格计算统一用
@grid-columns: 12变量控制，避免硬编码 - 别在循环里直接写
width: (100% / @cols) * @i，先算出单列基准宽：@col-width: round(percentage(1 / @grid-columns), 4)，再乘倍数
如何让@media断点和栅格列数联动，避免手动维护两套数值？
常见错误是把断点写死、列数写死，结果改一个就得翻三处。Less支持变量嵌套引用，可以靠@screen-sm这类变量驱动.make-grid-columns()的调用时机。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 定义断点映射表：
@grid-breakpoints: { xs: 0, sm: 576px, md: 768px, lg: 992px }; - 用
.each()遍历这个map，每轮生成对应断点下的.col-{key}-*类 - 关键点：每个断点下的列数用独立变量控制，如
@grid-columns-sm: 12; @grid-columns-md: 16;，避免全项目强耦合
calc()和Less变量混用时，为什么编译后出现calc(100% - 2rem)但实际没生效？
这不是Less的问题，而是CSS解析顺序导致的：如果calc()里混了Less变量（如calc(100% - @gutter)），Less会原样输出，但若@gutter带单位（比如@gutter: 1.5rem），编译后就是合法的calc(100% - 1.5rem)；但如果@gutter是纯数字（如@gutter: 24），就变成calc(100% - 24)——单位缺失，浏览器直接忽略整条声明。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 所有用于
calc()的变量必须显式带单位：@gutter: 1.5rem，而不是@gutter: 1.5 - 更稳妥的做法是封装函数：
.gutter-calc(@val) { width: calc(100% - @val); }，调用时传.gutter-calc(1.5rem) - 注意：Less 4.0+ 支持
unit()函数校验，可加一层保护：unit(@gutter, rem)报错提示
为什么用for循环生成响应式偏移（.offset-*）时，@i: 0起始值会导致类名重复或漏掉？
Less的.for()（或自定义递归循环）默认从1开始计数，但偏移类需要0起步（比如.offset-0表示不偏移）。如果强行设@i: 0，容易触发无限递归或索引越界，尤其配合when (@i =条件时边界判断失准。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 偏移类单独写一组循环，起始值设为
@i: 0，终止条件用when (@i （不是<code>） - 生成类名时用
~".offset-@{i}"确保字符串拼接，避免@i为0时被忽略 - 如果用
.each()替代.for()，需提前构造@offsets: 0 1 2 3 ...列表，比手动计数更稳
最易被忽略的是栅格系统的“收缩容差”——比如12列系统中，.col-6 + .col-6理论上刚好100%，但加上box-sizing: border-box和微小的四舍五入误差，可能多出0.01px。上线前务必在真实设备上用getBoundingClientRect()测实际宽度，别只信编译结果。
