纯CSS浮动无法实现真正瀑布流，因其按线性顺序排列而非寻找最低列，导致大面积留白；父容器塌陷、baseline间隙、column-count局限等问题进一步加剧视觉缺陷。
纯 CSS 浮动无法实现真正的瀑布流，所谓“大面积留白”不是渲染异常，而是浮动布局的固有行为——它根本不会把新元素插进当前最低列，只会按顺序贴着上一个浮动项的底部右侧排列。
浮动元素不寻找最低列，只线性追加
这是所有留白问题的根源。比如三列浮动容器中，第一列放了一张高图（300px），第二列放了一张矮图（120px），第三列也放矮图（140px）。此时第四张图不会落到第二列底部（120px处），而是直接跟在第三张图下方（140px + margin），导致第二列上方留下 160px 空白。
-
float: left元素之间没有“列高度感知”，浏览器不维护各列当前底部坐标 - 后续浮动项只检查前一个同向浮动元素的
offsetTop + offsetHeight，然后紧贴其右下角定位 - 响应式缩放时像素四舍五入误差会放大这种错位，空白更刺眼
父容器塌陷加剧视觉断裂
浮动子项脱离文档流后，父容器高度常为 0px 或远小于实际内容高度。这时背景色、边框消失，后续内容（比如页脚）直接顶到浮动区顶部，让留白区域看起来更大、更突兀。
- 用开发者工具检查父容器的
computed height，若为0或明显偏小，基本可确认塌陷 -
overflow: hidden或display: flow-root能让父容器重新包裹子项，但只是“显示完整”，不解决列间高度失衡 - 即使加了
::after { clear: both }，也只是防止后续内容上浮，无法让浮动项自动归位到低列
图片自身 baseline 对齐引入额外间隙
inline 元素，vertical-align: baseline 会在底部预留 descender 空间（约 4px），多张图并排时这个间隙叠加，加上浮动后行框计算，进一步撑开列间距，放大留白感。
- 仅设
float: left不影响vertical-align生效，必须显式写vertical-align: top或display: block - 若父容器有
line-height: 1.6，这个值仍参与行框高度计算，哪怕里面全是浮动图 -
font-size: 0可消除空格间隙，但对 baseline 留白无效；真正去底边需切断 inline 行为链
column-count 不是替代方案，只是“看起来像”
有人试图用 column-count: 3 模拟瀑布流，但它按内容流断行，不是按元素分列。一张高图可能被截成两半跨列，或因 break-inside: avoid 被整块推到下一列，反而制造更大空白。
-
column-gap必须显式设置，否则多列紧贴，视觉上无法识别“瀑布”层次 - JS 无法通过
getBoundingClientRect()获取某元素在第几列，交互逻辑（如点击加载更多）难以绑定列维度 - 当子项高度差异大时，列高严重不均，末尾列顶部大片留白，比浮动还明显
真正要解决大面积留白，得放弃“用浮动凑瀑布流”的思路——它本质是误用。现代方案要么用 JS 库（Masonry、Isotope）动态计算列高，要么用 grid + JS 做伪瀑布流；如果数据量不大且列数固定，display: grid 配合 grid-auto-flow: dense 和手动 grid-row 控制，反而是最可控的起点。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
