float无法实现真正瀑布流，因其按文档流顺序排列且只参考前一个同向浮动元素底部，导致列高不均时出现留白；高度塌陷必须解决，首选display: flow-root，次选overflow: hidden或clearfix。
不能真正实现瀑布流，但能凑合出“视觉近似”效果；高度塌陷必须解决，否则布局直接失效。
为什么 float 无法实现真正的瀑布流
浮动元素按文档流顺序排列，只看前一个同向浮动元素的底部位置，不会主动寻找当前各列最低处插入。结果就是：所有子项从左到右、从上往下线性堆叠，列高不均时第二列顶部被第一列长卡片卡住，下方大片留白。float: left + width 只能控制“每行放几个”，不能控制“落到哪一列底部”。所谓“浮动瀑布流”，本质是 JS 预计算 + margin-top 模拟出来的假效果，CSS 本身不参与列对齐。
必须解决的高度塌陷问题
父容器内全是 float 子项时，会完全塌陷为高度 0，背景、边框、后续元素全部错乱。解决方式不是“选一个”，而是按场景优先级选：
-
display: flow-root是首选：语义明确、无裁剪副作用、Chrome 64+/Firefox 58+/Safari 15.4+ 全支持 -
overflow: hidden可兜底，但要确认没有position: absolute弹层、阴影或动画溢出，否则会被截断 -
.clearfix::after仍需掌握，尤其兼容 IE11 或 CMS 输出不可控时；三要素缺一不可：content: ""、display: table（或block）、clear: both
定宽 + 浮动的最小可行写法
真要硬上，放弃“自动适配列数”和“动态加载”，只做静态、预知高度的场景：
- 父容器必须设
display: flow-root或等效清除方式 - 每个子项宽度锁死，如
width: 240px，禁用百分比、flex混用 - 所有子项高度需可预测：图片带
aspect-ratio或预设height，文字行数可控，避免加载中占位塌陷 - 不要给子项加
clear，它只会整行断开，不是列底对齐 - 响应式切换列数？那就得 JS 重算所有
margin-top，已脱离“纯 CSS”范畴
真正容易被忽略的点是：你写的“瀑布流”在 resize 或图片异步加载完成瞬间大概率重排错位——因为浮动不感知列高变化，而人眼对错位极其敏感。与其花时间调浮动，不如直接上 column-count（需配 break-inside: avoid）或轻量 JS 库。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
