纯CSS浮动无法实现真正瀑布流，因其按文档顺序线性排列、不感知列高、不查找最低列插入，导致留白、卡位、断裂等均为规范固有行为；clear、display:flow-root等仅缓解塌陷，不改变布局逻辑。
纯 CSS 浮动无法实现真正的瀑布流，这不是写法问题，而是模型缺陷——它根本不会把新元素插进当前最低列，所有“留白”“卡住”“断裂”都是浮动规范的必然结果。
float 元素不感知列高，只按文档顺序贴边
后续 float: left 元素只检查前一个同向浮动项的 offsetTop + offsetHeight，然后紧贴其右下角定位。它不维护各列底部坐标，也不回溯查找空隙。
- 三列中，第一列放一张 300px 高图，第二列放一张 120px 图，第三列放 140px 图；第四张图不会落到第二列底部（120px 处），而是跟在第三张图下方（140px + margin），留下 160px 空白
- 响应式缩放时像素四舍五入误差会放大错位，空白更刺眼
-
clear: both或伪元素清除仅防止后续内容上浮，无法让浮动项自动归位到低列
父容器塌陷与 baseline 间隙叠加视觉断裂
浮动元素脱离文档流，导致父容器 height 常为 0px 或远小于实际内容高度。此时背景、边框消失，页脚顶到浮动区顶部，让留白区域看起来更大、更突兀。
- 用开发者工具检查父容器的
computed height，若为 0 或明显偏小，基本可确认塌陷 -
display: flow-root或overflow: hidden能撑高容器，但只是“显示完整”，不解决列间高度失衡 -
默认是
inline元素，vertical-align: baseline在底部预留约 4px descender 空间，多张图并排时这个间隙叠加，进一步撑开列间距 - 必须显式设
vertical-align: top或display: block才能切断 inline 行为链
column-count 不是替代方案，只是“看起来像”
有人误以为 column-count: 3 是浮动的升级版，但它按内容流断行，不是按元素分列。一张高图可能被截成两半跨列，或因 break-inside: avoid 被整块推到下一列，反而制造更大空白。
-
column-gap必须显式设置，否则多列紧贴，视觉上无法识别“瀑布”层次 - 子元素需设
break-inside: avoid，否则图片或卡片可能被截断在两列之间 - 不能嵌套在
display: flex的父容器里直接生效——flex容器内部不继承column布局 - JS 读取
getBoundingClientRect()返回的是文档流位置，不是列内坐标，交互逻辑难绑定
真瀑布流必须靠 JS 动态追踪列高，CSS 无解
纯 CSS 无法动态比较各列底部 Y 坐标，所以得用 JS 维护一个数组记录每列当前总高度，每次取最小值那列插入新元素。
-
offsetHeight在图片未加载完成时为 0，务必监听img.onload或用IntersectionObserver触发重排 - 批量插入时要缓存列高数组，避免每张图都查 DOM；防抖
window.resize，否则频繁重排 - Chrome 90+ 中，JS + float 方案的 layout thrashing 极其明显：100 个子项可能造成 >200ms 卡顿
- 移动端 Safari 对
float的重绘优化更弱，且不支持will-change: transform来缓解
真正容易被忽略的点是：所谓“浮动瀑布流”从来就不是一种布局策略，而是一系列 hack 的临时拼凑。当你开始为每张图算 margin-top、为每列加 clear、为塌陷写 ::after，其实已经承认了浮动不是解法——它就是问题本身。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
