@while 不适合构建栅格系统，应改用 @for。它无法可靠生成确定数量的类名，且易因变量管理不当导致无限循环或漏生成。
@while 不适合构建栅格系统，应改用 @for。它无法可靠生成确定数量的类名，且易因变量管理不当导致无限循环或漏生成。
为什么 @while 不能替代 @for 生成栅格类
@while 依赖手动维护计数器变量，而栅格系统要求「严格、可预测、全覆盖」的类名输出（如 .col-1 到 .col-12）。一旦 $i 初始化错误、递增逻辑遗漏或条件边界写错，就可能：
- 漏掉
.col-12—— 实际布局中 12 列是常用满宽基准，漏掉即大屏失效 - 生成
.col-13等越界类 —— CSS 无报错但语义错误，DevTools 里看不出异常 - 陷入死循环 —— Sass 编译卡住，终端无响应，需强制终止
而 @for $i from 1 through 12 是闭区间声明，编译器保证执行 12 次，结果确定、可验证、零歧义。
@while 写栅格的典型错误示例
下面这段代码看似能跑通，但隐患极深：
立即学习“前端免费学习笔记（深入）”；
$i: 1;
@while $i <= 12 {
.col-#{$i} {
width: percentage($i / 12.0);
}
$i: $i + 1;
}
问题在于：
$i 是松散边界，若某处误写成 <code>，立刻漏掉最后一项- 变量
$i是全局可变状态，嵌套在@each断点中时极易被覆盖或重置错乱 - 无法与
$grid-columns变量联动 —— 改列数就得同步改所有@while的上下限和步长，维护成本陡增
真正该用 @while 的场景（不是栅格）
@while 在 SCSS 中适用的是「未知迭代次数」或「条件驱动」的生成，比如：
- 按字体大小阶梯生成
.text-xs~.text-xxl，但上限由$font-sizesmap 长度决定，不固定 - 递归生成多层嵌套的
.nav-item .nav-item .nav-item菜单深度，取决于数据结构 - 计算某个值衰减到阈值以下所需的步数（如透明度渐变）
这些场景中，循环终点不可预设，@while 才有存在意义。栅格列数是设计契约，必须精确可控 —— 这正是 @for 的设计使命。
如果硬要用 @while，至少守住这三条底线
虽不推荐，但若项目已有历史代码或特殊约束必须用 @while，请确保：
- 用
$i: $i + 1且只出现一次，禁止在循环体内多次赋值 - 上限写死为
$grid-columns变量（而非数字 12），并提前!default声明 - 循环外加断言：
@if $grid-columns ，防传入非法值
即便如此，仍无法规避「生成顺序不可控」「调试时变量快照难捕获」等底层缺陷。真正省事的做法，是直接换回 @for —— 它不是语法糖，而是为这类任务存在的原生机制。
