SCSS @for 循环无法实现真正瀑布流，因其仅能静态生成等宽栅格类（如.col-3{width:33.333%}），而瀑布流需运行时动态计算各列高度并插入最短列底部，必须依赖CSS columns（伪瀑布流）、grid（草案支持）或JS库（如Masonry）。
SCSS @for 循环无法直接实现瀑布流布局
瀑布流（Masonry）本身不靠列宽百分比分配实现，CSS 原生 column-count 或 display: grid 配合 grid-auto-flow: dense 也不等于瀑布流；真正支持高度不等子项垂直错落的，只有 column-count + break-inside: avoid（伪瀑布流），或 JavaScript 库（如 Masonry、CSS container-query 尚未普及）。SCSS 的 @for 只能静态生成列宽规则，对 DOM 高度分布毫无感知——它算不出“第 3 个元素该掉到哪一列底部”，那不是编译时能决定的事。
用 @for 算列宽百分比只适用于等高栅格（非瀑布流）
如果你实际想要的是「N 列等宽响应式栅格」，比如 2 列占 50%、3 列占 33.333%、4 列占 25%，这时 @for 才有用武之地。它本质是批量生成 .col-2、.col-3 这类工具类，而非解决瀑布流。
-
@for $i from 2 through 12可循环生成从 2 到 12 列的 class - 每轮计算
100% / $i，但必须用percentage(1 / $i)或#{100 / $i}%避免整数除法（如100 / 3在旧版 Sass 中得 33，不是 33.333） - 生成的 class 仅控制宽度，不处理浮动、间隙或响应断点——这些需额外写
@for $i from 2 through 6 {
.col-#{$i} {
width: #{percentage(1 / $i)};
}
}
编译后得到：.col-2 { width: 50%; }、.col-3 { width: 33.33333%; }……但所有子项仍按文档流自上而下排列，不是瀑布流。
真瀑布流必须放弃纯 CSS 列宽计算逻辑
当你看到「用 SCSS 实现瀑布流」这类说法，大概率混淆了两个概念：一是栅格系统（width-based），二是布局算法（height-based）。后者依赖运行时测量和重排，SCSS 编译完就结束了，插不上手。
立即学习“前端免费学习笔记（深入）”；
- CSS
columns属性可模拟简单瀑布流，但子项不能跨列、不能指定顺序，且column-gap会破坏容器内边距逻辑 -
display: grid的grid-template-columns: repeat(auto-fill, minmax(300px, 1fr))是响应式等宽，不是瀑布流 - 若坚持用 CSS，唯一接近的方式是为每列单独写
float: left+ 固定宽度容器，再用 JS 动态 append 元素到最短列——此时 SCSS 连列宽都不用算，JS 控制即可
容易被忽略的关键点：浏览器原生 column-count 的限制
很多人尝试用 column-count: 3 + column-gap 做瀑布流，却忽略三个硬伤：
- 子元素内部
margin和padding会受 column 分割影响，出现意外断行 -
break-inside: avoid并非 100% 可靠，在 Safari 中常失效 - 无法控制某元素强制进入特定列，也无法响应滚动动态加载新项
所以，当设计稿明确要求「图片高度不一、垂直无缝衔接、首屏即呈现」，别在 SCSS 里死磕 @for 百分比——该上 Masonry 库或 display: grid + container query（Chrome 117+）就上，编译时的数学游戏解决不了运行时的几何问题。
