瀑布流Grid最小可行配置是grid-template-columns: repeat(auto-fill, minmax(280px, 1fr))，因auto-fill强制预留所有列槽位，避免列跳变与塌陷；grid-auto-rows须用minmax(100px, auto)兜底并适配内容；JS分配span值需在图片/字体加载完成后再用getBoundingClientRect().height精确计算。
grid-template-columns: repeat(auto-fill, minmax(280px, 1fr)) 是能跑起来的最小可行配置，但直接照抄会错——真正决定瀑布流是否“不规则又不歪”的，是三件事：列槽位保留方式、行高基准设定、以及内容高度何时被读取。
为什么 auto-fill 不是可选项，而是必须项
用 auto-fit 会导致列数跳变甚至网格塌陷。现象包括：刚加载时只显示一列，滚动后突然变成三列；空数据时整个容器缩成一条线；高卡片被强行拉宽、破坏密度。
auto-fill 强制浏览器预留所有可能列的轨道，哪怕某列暂时为空——这是瀑布流能“预判”后续元素落点的前提。Grid 不会动态重排，它只按轨道分配，没槽位就只能堆在一列里。
- 别信“
fit更智能”：在瀑布流场景下，它收缩空列的行为就是 bug 源头 -
minmax(280px, 1fr)中的280px是底线，小屏需降为160px或更低，否则列过窄只剩图标 - 列数变化取决于容器宽度，不是视口宽度——所以监听
window.resize是错的
grid-auto-rows: minmax(100px, auto) 为什么不能简写
写成 100px 会裁剪内容；写成 auto 在旧版 Chromium（如 Chrome 90 前）会塌陷；fit-content 在 Grid 行高中根本不生效。
minmax(100px, auto) 是唯一稳妥解：给最小高度兜底防视觉塌陷，又允许卡片内容自然撑开行高。这个值不是魔法数字——它要略大于卡片内文最小行高（含 padding），否则文字换行错乱。
立即学习“前端免费学习笔记（深入）”；
- 别设
1px：浮点误差会被放大，跨行计算失准 - 别依赖
line-height或height: fit-content替代：它们不参与 Grid 行轨道生成 - 图片加载完成前，
offsetHeight可能为 0，此时行高计算全错
JS 动态分配时，grid-row-end 的 span 值怎么算才准
Grid 本身不读取真实高度，span 必须由 JS 计算并注入内联样式。关键不在“怎么算”，而在“什么时候算”和“用什么量”。
- 用
getBoundingClientRect().height，不是offsetHeight：前者包含渲染后的真实尺寸，避开字体回流、图片未加载等抖动 - 必须等所有
<img>触发load或完成decode()，否则高度为 0 - 计算公式是
Math.ceil(item.getBoundingClientRect().height / 100)，分母必须和grid-auto-rows的最小值一致 - 插入方式选
appendChild，不是改order：后者依赖渲染顺序，resize 后容易错位
响应式重排最容易漏掉的三个时机
列数变化 ≠ 窗口大小变化。一个容器宽度微调，就可能让 minmax() 多挤出一列——但如果你只监听 window.resize，这次变化根本捕获不到。
- 用
ResizeObserver监听 Grid 容器自身宽度，不是window - 图片懒加载完成（
IntersectionObserver+img.decode()）后，必须重新跑分配逻辑 - 字体加载完成（
document.fonts.load）也会改变卡片高度，尤其含多行文本的卡片
这三件事都不报错，但会让瀑布流看起来“歪了”或者“卡住”——错位往往不是代码写错了，而是高度测量时机错了。
