纯css无法实现真瀑布流，需js参与；grid-template-rows:masonry是当前最接近原生解法的方案，仅chrome116+和edge116+支持；display:grid+grid-auto-flow:dense是兼容性最好的纯css模拟方案。
纯 CSS 能做出接近瀑布流的视觉效果，但“真瀑布流”（每列独立撑高、图片不切割、底部自然对齐）目前仍需 JS 参与；现代浏览器中 grid-template-rows: masonry 是最接近原生解法的方案，但它只在 Chrome 116+ 和 Edge 116+ 中可用，Firefox 和 Safari 依然不支持。
用 display: grid + grid-auto-flow: dense 模拟瀑布流（兼容性最好）
这是当前项目中最稳妥的纯 CSS 方案，不依赖新特性，所有现代浏览器都支持。核心是让 grid 容器自动填充空隙，而不是留白。
-
grid-template-columns: repeat(auto-fit, minmax(280px, 1fr))—— 小屏最少一列，大屏自动加列，避免写死列数 - 必须加
grid-auto-flow: dense，否则高图下方会留大片空白，后续短图不会上浮填补 - 每张图需有明确高度预期：靠
aspect-ratio（推荐）或容器伪元素padding-bottom预留空间，否则图片加载后会塌陷重排 - 别设
overflow: hidden在 grid 容器上，否则跨行 span 的元素可能被截断
为什么 column-count 不是真瀑布流
它只是把文档流按高度切片分栏，不是按 item 分配——一张 800px 高的图会被硬生生从中间“撕开”，出现在两列里，且无法控制单图宽度或点击区域。
- 常见错误：
img默认是inline，会在列底多出 4px 空隙；修复只需加img { display: block } -
break-inside: avoid只能防止单个 item 被切割，不能解决列高不均问题 - Safari 对
column-gap渲染存在 1px 偏移，Chrome 下loading="lazy"可能延迟占位，导致首屏跳变
必须用 JS 的真实场景（图片高度不可预知）
当服务端无法提供宽高比、图片来自用户上传、或需要滚动加载新项时，纯 CSS 无法可靠预估高度，JS 是唯一选择。
- 优先用
masonry-layout（v4.2.2+），它监听imagesLoaded后再布局，避免 height=0 导致错位 - 初始化必须等 DOM 就绪且图片至少已触发
load或error，不能只靠DOMContentLoaded - 动态添加新图时调用
layout.appended(newItems)，别用reloadItems()，后者会重算全部 item，性能差 - 若父容器有
transform或filter，masonry-layout的绝对定位会偏移，需额外包裹一层无样式容器
React/Vue 中瀑布流组件的渲染陷阱
瀑布流本身不关心框架，但框架的 re-render 行为会放大布局问题：每次新增图片触发全量更新，grid 会丢弃原有轨道线（grid lines），重新计算所有行高，造成卡顿和跳动。
- 不要把整个瀑布流封装成一个“黑盒组件”，应把每个
img作为独立可缓存单元 - 用
key控制 item 稳定性，避免因数组顺序变化导致重复 mount/unmount - 服务端若能返回
width/height属性，直接写进 HTML，Chrome/Firefox 会据此推导aspect-ratio，无需 JS 补算
真正难的不是“怎么排”，而是“怎么稳”：图片加载时机、宽高比是否可信、框架更新节奏、浏览器渲染差异——这些细节叠加起来，才是瀑布流在生产环境里频繁翻车的根本原因。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
