纯CSS浮动无法实现瀑布流，因其按线性顺序排列元素，不能智能选择最低列插入，导致列高不均和空白；column-count仅适用于文本分段；现代稳定方案是JS库或grid+JS伪瀑布流。
浮动实现瀑布流为什么行不通
纯 CSS 浮动（float）无法真正实现“视觉上错落有致、内容按列自然填充”的瀑布流效果，它只能做到多列并排、元素从左到右依次堆叠——这本质是「多列流」，不是「瀑布流」。
关键原因在于：float 元素脱离文档流后，后续浮动元素只看前一个同向浮动元素的底部位置，不会“智能寻找当前各列最低处插入”。结果就是：所有元素从左往右、从上往下线性排列，列高不均时出现大片空白，尤其在响应式或动态加载场景下更明显。
- 常见错误现象：
float: left+ 固定宽度容器 → 第二列顶部被第一列长卡片卡住，下方留白严重 - 使用场景误判：把 Masonry 风格的图床、商品列表当成可用
float搞定的“多栏布局” - 兼容性陷阱：即使加了
clear: both或伪元素清除，也只解决父容器塌陷，不解决列间高度对齐问题
用 column-count 模拟瀑布流的边界条件
column-count 是 CSS 原生最接近瀑布流的方案，但它按内容流自动分段，不是按元素分列——这意味着单个子元素不能跨列，也不能控制某元素一定落在第几列。
适用前提是：子项高度差异不大、允许文本式断行（比如文章段落），且不需要点击区域或交互逻辑绑定到“列维度”。
立即学习“前端免费学习笔记（深入）”；
- 必须设置
column-gap，否则多列紧贴，视觉上无法区分“瀑布”层次 - 子元素需设
break-inside: avoid，否则图片或卡片可能被截断在两列之间 - 无法响应鼠标事件精确定位列：JS 读取
getBoundingClientRect()返回的是文档流位置，不是列内坐标 - Flex/Grid 容器内部不继承 column 布局，所以不能嵌套在
display: flex的父容器里直接生效
真正可用的现代方案只有 display: grid + grid-auto-flow: dense
CSS Grid 本身不原生支持“按列优先填充”，但配合 grid-template-rows: masonry（目前仅 Firefox 支持）仍属实验特性。现阶段稳定落地的做法，是用 JavaScript 配合 CSS Grid 做“伪瀑布流”：先用 JS 计算每列当前高度，再给每个子元素设置 grid-row 和 grid-column。
不过，如果你坚持纯 CSS，唯一能逼近效果的是：
.masonry {
display: grid;
grid-template-columns: repeat(3, 1fr);
grid-auto-rows: 10px;
grid-auto-flow: dense;
}
.item { margin-bottom: 1em; }
这个写法依赖浏览器对 grid-auto-rows 的解释和 dense 算法回填能力，实际表现不稳定——Chrome 和 Safari 对 dense 的处理偏向保守，经常不触发回填，导致空洞依然存在。
- 别指望
grid-row: span 2能自动避开空白：它只会向下占位，不管左侧是否有更短的列可插 -
grid-auto-flow: column是按列填充，但要求显式定义行数，不适合不定高内容 - 性能影响明显：大量子元素 +
dense会显著增加布局计算时间，滚动时可能掉帧
生产环境该选什么
真实项目里，除非目标用户 100% 使用 Firefox，否则不要押注 grid-template-rows: masonry；放弃 float 和纯 column-count 的尝试；grid + dense 只适合静态、元素少、高度可控的展示页。
绝大多数情况，应该用 JS 库（如 masonry-layout、muuri）或现代框架封装的组件（React 的 react-virtualized/Masonry、Vue 的 v-masonry）。它们通过维护列高数组 + 绝对定位 + transform 实现精确插入，同时支持懒加载、动画、拖拽重排等需求。
最容易被忽略的一点：瀑布流容器必须有明确高度或 max-height 才能触发滚动，否则内容会不断向下撑开页面——这不是布局问题，是容器上下文缺失导致的 DOM 行为，调试时常常花半小时找“为什么没滚动”，其实只是忘了设 overflow-y: auto 和高度约束。
