目前唯一能原生实现Pinterest式瀑布流的CSS方案是grid-template-rows: masonry，但它仅在Chrome 117+、Firefox 119+、Safari 17.4+中可用，且必须显式定义grid-template-columns、禁用手动行定位、避免嵌套flex/grid容器，否则退化为等高网格。
目前唯一能原生实现 Pinterest 式瀑布流的 CSS 方案是 grid-template-rows: masonry，但它只在 Chrome 117+、Firefox 119+、Safari 17.4+ 中可用，且必须满足硬性前提，否则会退化为等高网格。
为什么 grid-auto-flow: row + minmax() 不是瀑布流
常见错误写法：grid-template-columns: repeat(auto-fill, minmax(250px, 1fr))); grid-auto-flow: row;。这只会生成“等高卡片墙”，因为 Grid 每行高度由该行最高项决定，后续项不会自动落入更短列的底部。即使加了 grid-auto-flow: dense，也只是调整渲染顺序，不改变列高同步逻辑，视觉上仍是阶梯状，不是错落感。
grid-template-rows: masonry 的三个不可绕过前提
这个特性不是“设了就灵”，漏掉任意一条都会失效：
-
grid-template-columns必须显式定义列数或列宽，例如repeat(3, 1fr)或300px 300px 300px；auto-fill/auto-fit会直接禁用 Masonry 行为 - 不能使用
grid-row、grid-row-start、grid-row-end等手动定位属性，否则浏览器立即回退到普通 Grid 布局 - 容器子元素必须是卡片本身，不能嵌套一层
display: flex或display: grid的 wrapper —— 这会干扰列高测量，导致错位
图片加载、字体回流、响应式切换这三件事怎么稳住
Masonry 布局最脆弱的点不在 CSS 写法，而在运行时内容变化：
立即学习“前端免费学习笔记（深入）”；
- 图片未加载时高度为 0，初始渲染错位：给
img加display: block; height: auto;，并用aspect-ratio占位；Firefox 支持弱，fallback 到padding-top: 75% - 异步插入新卡片后不重排：调用
element.scrollIntoView({ block: 'nearest' })或临时改transform（如element.style.transform = 'scale(1)'）强制重绘 - 响应式断点切换列数时，旧列高缓存残留：监听
resize或orientationchange后，清空容器再重新 append 子节点，或触发一次container.style.display = 'contents'; setTimeout(() => { container.style.display = ''; }, 0);
真正难的从来不是写出那两行 Masonry CSS，而是让图片加载、字体回流、断点切换这三件事不互相打架——它们共同决定了用户看到的是流畅瀑布，还是抖动卡顿的拼图。
