无法实现真正瀑布流，因grid-auto-rows为所有隐式行分配统一高度，导致列间强制对齐、内容溢出或留白，违背瀑布流列高自适应、错落排列的本质要求。
grid-auto-rows 设固定高度无法实现真正瀑布流
直接用 grid-auto-rows: 200px 搭配 grid-template-columns 只能做出「等高栅格」，不是瀑布流。瀑布流要求每列高度自适应内容、列间不强制对齐，而 CSS Grid 的 grid-auto-rows 是为**隐式行轨道**分配统一高度，所有行都会被拉平，内容超长会溢出或被裁剪，视觉上仍是“阶梯状”而非“错落感”。
- 常见错误现象：
grid-auto-rows: 250px后，短内容项底部留白巨大，长内容项触发滚动条或溢出容器 - 使用场景误判：适合卡片高度一致的相册/菜单布局，不适合图文混排、标题长度差异大的新闻/商品列表
- 性能影响：固定行高 + 大量内容时，浏览器仍需计算所有行位置，但视觉无效，纯属浪费布局开销
真正可行的 Grid 瀑布流只有一种方式：column-count + column-fill
CSS Grid 本身不支持原生瀑布流（Firefox 曾实验 grid-template-rows: masonry，但已弃用），目前唯一稳定跨浏览器方案是多列布局（column-count）。它按内容流自然分列，高度自动不等，视觉即瀑布流。
- 关键参数：
column-count: 3控制列数，column-gap: 16px设置列间距，column-fill: balance（默认）确保各列高度尽量均衡 - 兼容性：Chrome 50+、Firefox 13+、Safari 10.1+、Edge 79+ 均支持，无需前缀
- 与 Grid 的区别：它不依赖
display: grid，而是display: block容器 + 列式流，子项必须是普通块级元素（不能是grid-item或flex-item） - 示例结构：
.waterfall {
column-count: 3;
column-gap: 16px;
}
.waterfall > * {
break-inside: avoid; /* 防止单个卡片被断成两截 */
margin-bottom: 16px;
}如果坚持用 display: grid，只能模拟瀑布流效果
通过 JavaScript 测量子项高度 + 动态设置 grid-row-end，或借助 grid-template-rows: repeat(…) 配合 JS 计算行高数组。但这已脱离纯 CSS 范畴，且维护成本高。
- 容易踩的坑：
grid-row-end: span 2无法响应内容变化，需监听 resize / DOM 变更并重算；服务端渲染时 JS 未执行，首屏仍是错位的 - 参数差异：用
grid-auto-flow: dense可让小卡片填空，但无法解决高度不一致导致的视觉断裂，反而加剧混乱 - 性能警告：每新增一个子项都可能触发全量重排，100+ 项时明显卡顿
为什么不要强行给 grid-auto-rows 加单位值来“凑”瀑布流
有人尝试 grid-auto-rows: minmax(200px, auto) 或 grid-auto-rows: 1fr，但这只是让每行最小 200px 或均分剩余空间，依然无法让列独立伸缩。Grid 的行轨道是横向贯穿所有列的，不是按列划分的。
立即学习“前端免费学习笔记（深入）”；
- 典型错误现象：三列布局下，第 1 列第 1 项高 300px，第 2 列第 1 项高 120px，但两者被锁在同一行轨道里，结果第 2 列出现大片空白
- 本质限制：CSS Grid 是二维网格系统，设计目标是行列对齐，瀑布流是一维流式分列，二者模型冲突
- 真正需要关注的点：是否必须用 Grid？如果只是为了响应式多列，
column-count更轻量；如果已有 Grid 布局逻辑，建议把瀑布流区域单独抽离为column容器，避免混合模型
