grid-row: span n 不能自动适配图片高度，因其跨度基于行轨道数而非像素；未设 grid-auto-rows 时行为不可控，纯 css 瀑布流在 chrome/edge 中不可靠，columns 是当前最兼容的近似方案。
grid-row: span N 为什么不能自动适配图片高度
因为 grid-row 的 span 值是「行数」，不是「像素高度」，它依赖于显式定义的行高（grid-template-rows）或隐式行高（grid-auto-rows）。如果没设 grid-auto-rows，浏览器会按内容撑开每行，但 span 2 仍只跨 2 个「行轨道」，而非 2 倍图片实际高度。
- 常见错误现象：
grid-row: span 2在图片高度差异大时完全失效，卡片重叠或留白严重 - 必须配合
grid-auto-rows: 10px（或具体值）才能让span有明确参照；但固定值又无法响应图片真实高度 - 真正可行的做法是放弃靠
grid-row控制高度跨度，改用grid-template-rows: masonry（仅 Firefox 支持）或退回到 JS 驱动的绝对定位 - Chrome/Edge 目前不支持
masonry值，所以纯 CSS 瀑布流在主流浏览器里本质不可靠
用 grid-area 模拟瀑布流时的定位陷阱
grid-area 可以手动指定每个子项的行列范围（如 grid-area: 1 / 1 / 3 / 2），但问题在于：你得提前知道每张图该占几行——而这个「几行」取决于图片原始宽高比、容器宽度、以及当前列的已占用高度。
- 使用场景：只有在图片尺寸完全可控（如全部等比缩放到统一高度）、且列数固定时，才适合手写
grid-area - 参数差异：
grid-area: row-start / col-start / row-end / col-end，注意row-end是「结束行线号」，不是跨距 - 容易踩的坑：用 JS 计算后直接写死
grid-area，结果窗口 resize 或字体加载导致布局偏移；或者没重置grid-column-start，所有项挤在第一列 - 性能影响：大量内联
grid-area值会让 CSSOM 树变大，对首屏渲染无益；不如用 JS 动态计算 top/left
为什么 display: grid + grid-template-columns: repeat(auto-fill, minmax(240px, 1fr)))) 不等于瀑布流
这只是等宽多列布局，所有子项仍按「文档流顺序」逐行填满，每行高度由该行最高项决定，视觉上仍是「阶梯状」，不是 Pinterest 那种各列独立下落的效果。
- 常见错误现象：三列布局中，第二列第一项被第一列一个超长卡片“顶”到很下方，中间出现大片空白
- 关键区别：
grid的默认排列是「行优先」，而瀑布流本质是「列优先」——每个新项找当前最短列插入 - 兼容性影响：即使加上
grid-auto-flow: dense，也无法改变项的插入顺序逻辑，只是尝试填空，不能解决高度错位 - 替代思路：CSS
column-count+break-inside: avoid更接近瀑布流行为，但不支持 item 跨列、响应式控制弱、图片易被截断
真正能落地的轻量级方案：CSS columns + object-fit
不用 JS 就想近似 Pinterest 效果，columns 是目前唯一能在 Chrome/Firefox/Safari 全平台稳定工作的 CSS 方案，前提是接受它对 item 的「截断容忍度」和有限控制力。
立即学习“前端免费学习笔记（深入）”；
- 实操建议：
column-count: 3或column-width: 240px，子项设break-inside: avoid防止图片被切开 - 图片适配：必须加
img { width: 100%; height: auto; object-fit: cover; }，否则在窄列中变形或溢出 - 容易被忽略的点：父容器需设
column-gap（不能只靠 margin），且所有子项不能有display: inline-block或浮动，否则 column 布局会失效 - 限制明显：无法实现「点击放大后保持列对齐」、「拖拽排序」、「无限滚动懒加载时列高重算」——这些都得靠 JS 补足
