纯css grid无法实现真正瀑布流，因masonry仅chrome 116+支持且需同时满足显式列宽、无跨行跨列、固定容器高度等严苛条件；生产环境须用grid-auto-flow:column配合js动态分配或column-count降级。
纯 CSS Grid 无法实现真正的瀑布流，grid-template-rows: masonry 目前仅 Chrome 116+ 支持，其余浏览器（Firefox、Safari）完全不识别，且生效条件极其苛刻；生产环境必须用 grid-auto-flow: column + JS 动态分配，或退而求其次用 column-count 降级。
为什么 grid-template-rows: masonry 不能直接用
它不是“开了就灵”的开关，必须同时满足：显式写死 grid-template-columns（不能用 auto-fill 或 auto-fit）、子项无跨行跨列、容器有明确 height 或 max-height、子项内部不能有 float / position: absolute / contain: layout。哪怕漏一条，Chrome 也会静默回退为普通行流布局——视觉上变成单列，而非瀑布。
更关键的是：@supports (grid-template-rows: masonry) 在 Safari 和 Firefox 中永远返回 false，因为它们根本不解析该语法，无法可靠做特性检测。
- 移动端写
@media (max-width: 480px) { grid-template-columns: 1fr; }是安全的；但写repeat(auto-fill, minmax(280px, 1fr))就会让masonry失效 -
height: 70vh在小屏下易留白，建议配合媒体查询动态调高，比如90vh
grid-auto-flow: column + JS 分配是最稳方案
Grid 负责列宽、间距、断点；JS 只管把每个元素塞进当前最短列。逻辑清晰、兼容性好、能应对图片加载延迟和字体重排。
-
grid-template-columns: repeat(auto-fill, minmax(240px, 1fr))控制列数，auto-fill保留空列占位，避免小屏初加载只出一列 -
grid-auto-flow: column让浏览器按列顺序排列，为 JS 重排打基础 - JS 不靠
order属性（易受 CSS 优先级干扰），直接用appendChild移动 DOM 节点，确保渲染顺序与视觉一致 - 每次插入后必须用
item.getBoundingClientRect().height更新列高，不能用offsetHeight（含边框/滚动条误差）
图片和容器样式细节决定成败
Grid 只排位置，不管内容怎么缩。图片没处理好，再准的 Grid 布局也会错乱。
- 图片必须加
img { display: block; width: 100%; height: auto; }，否则vertical-align: baseline会在底部多出 4px 空白，导致列高计算失准 - 若需裁剪，父容器（如
<figure></figure>）必须设aspect-ratio（如4/3），再配object-fit: cover；只写width: 100%不控高，图片会拉伸变形 -
gap控制项间间距，别在 item 上写margin，否则干扰 JS 对高度的测量 -
grid-auto-rows: minmax(100px, auto)的真实作用是防止极矮卡片塌陷，并给渲染引擎一个最小轨道参考；别写成auto单独值，旧版 Chromium 会忽略
响应式重排最容易漏掉的两件事
窗口缩放不仅改变列数，还会让已分配的节点顺序立刻失效。只监听 window.resize 不够，因为频率太高且不反映容器实际尺寸变化。
- 必须用
ResizeObserver监听容器宽度，而不是整个window - 重排逻辑要防抖，比如
setTimeout(() => { redistributeItems() }, 100)，等浏览器完成 layout 再执行，避免反复触发回流 - 懒加载图片完成后再触发一次重排，否则 JS 初始计算时高度为 0，后续图片加载会撑开列高却没更新其他列的分配状态
真正麻烦的从来不是怎么写第一版，而是图片加载异步、字体加载异步、用户缩放、服务端渲染首屏错乱——这些细节堆在一起，才决定瀑布流到底“稳不稳”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
