grid-auto-rows: minmax(100px, auto)是瀑布流核心，它为隐式行设最小高度并允许内容撑开；grid-template-rows不适用，因其仅控显式行且会破坏错落感。
grid-auto-rows + minmax() 是核心，不是 grid-template-rows
用 grid-template-rows 写死行高会彻底破坏瀑布流的“错落感”，真正起作用的是隐式轨道：浏览器自动为每个新项目生成一行，并按 minmax(100px, auto) 动态分配高度。这个 100px 是最小行高（防过矮塌陷），auto 才是关键——它让每行高度由内容（图片）真实撑开。
常见错误是把 Grid 当 Flex 用，给容器设 grid-template-columns: repeat(3, 1fr) 后就停手，结果所有图片被强行塞进固定三行，变成“等高栅格”，不是瀑布流。
- 必须配合
grid-auto-flow: dense（可选但推荐），让短图能向上回填空隙 - 容器需设
display: grid和grid-auto-rows: minmax(100px, auto) - 列数用
grid-template-columns: repeat(auto-fill, minmax(280px, 1fr)))实现宽度驱动自适应，比媒体查询更简洁 - 图片本身要设
width: 100%和height: auto，避免拉伸变形
为什么不能直接用 grid-row: span N？
手动计算并写死 grid-row: span 2 或 grid-row: 1 / 3 看似可控，但实际极难维护：每张图片高度不同，且响应式下宽度变化会导致高度重算；JS 动态注入时还要监听图片加载完成、重排 DOM、再重新计算 —— 容易漏掉 onload、触发多次重绘、移动端卡顿。
Vue 示例里用 image.height * 200 / image.width 算 gridRow 值，本质是模拟 Masonry 的 JS 分发逻辑，已脱离“纯 CSS”范畴，且在 SSR 或首屏直出时不可用。
立即学习“前端免费学习笔记（深入）”；
- 服务端无法获取图片原始尺寸，除非后端提前存宽高字段
- 前端
new Image()加载可能被缓存干扰，或因 CORS 失败静默失败 - 一旦图片宽高比突变（比如竖图变横图），整个网格错位，调试成本高
column-count 方案和 Grid 方案怎么选？
如果只要求“列数随屏幕变”，不强求每列顶部对齐、也不介意图文混排时卡片被截断，column-count + 媒体查询是最轻量、兼容性最好的方案（Safari 14+ 已稳定支持）。但若页面含标题、按钮、描述文本等复杂子项，或需要精确控制某张图始终完整显示，Grid 是唯一可靠选择。
-
column-count必须加break-inside: avoid，否则 Safari/Chrome 都可能劈开图片 - Grid 不吃这一套，天然按项目整体分配空间，无需防截断
- Grid 支持
aspect-ratio和object-fit组合控制图片缩放，column-count下图片容易溢出列宽 - 真·响应式优先场景（如设计稿要求“小屏单列、中屏双列、大屏四列”），媒体查询 +
column-count更直观；若需求是“每列至少 280px，能塞几列塞几列”，用 Grid 的minmax()更自然
移动端适配最容易忽略的坑
很多人写了 grid-template-columns: repeat(auto-fill, minmax(280px, 1fr))) 就以为万事大吉，结果 iPhone 上列数爆炸（因为 viewport 缩放或 UA 样式干预），或者安卓微信内置浏览器里 grid-gap 变成 0。
- 务必加
viewportmeta：<meta name="viewport" content="width=device-width, initial-scale=1">，否则 iOS Safari 会强制缩放容器 - 避免用
rem设grid-gap，改用px或em，某些安卓 WebView 对 rem 解析异常 - 测试时打开真机远程调试，别只信 Chrome DevTools 的模拟器 —— 微信、QQ、微博等壳浏览器对 Grid 的
auto-fill支持仍有差异 - 如果用到
aspect-ratio，iOS 16.4+ / Android Chrome 109+ 才完全支持，旧版本需 fallback 到 padding-top 技巧
