不推荐用 float 布局做瀑布流，因其无法自动将元素贴至最短列底部，需 JS 预计算高度并手动设置 margin-top 模拟，存在塌陷、重排卡顿、响应式维护难等问题，现代应优先选用 CSS Grid 或 Masonry 库。
float 布局做瀑布流？先说结论：不推荐，但能凑合
纯 float 实现不了真正意义上的瀑布流——它没法让后续元素自动“贴”到前一列最短的底部。你看到的所谓“浮动瀑布流”，其实是靠 JavaScript 预计算每列高度、手动插入 clear 或控制 margin-top 模拟出来的，CSS 本身不参与列高对齐。
为什么 float + width 计算只能出“假瀑布流”
常见做法是：用 JS 算出容器宽度，除以子项固定宽度，得到列数；再为每个子项设置 float: left 和对应列的 margin-top。问题在于：
-
float的脱离文档流特性会让父容器高度塌陷，必须用overflow: hidden或伪元素::after清除浮动，否则布局错乱 - 子项高度不一致时，
float只按行排列，不会跨行“掉落”到前面更短的列尾部 - 响应式场景下，列数变化时需重新计算所有
margin-top，JS 逻辑容易漏掉重排或 resize 事件 - IE8+ 虽支持
float，但getBoundingClientRect()在低版本中精度差，导致列高误判
如果非要用 float 模拟，关键三步不能跳
前提：子项高度已知或可预估（比如图片带宽高比、文字行数可控）；列数固定或仅在断点处切换。
- 用
document.documentElement.clientWidth而不是window.innerWidth获取可用宽度，避免滚动条干扰 - 列宽 = (容器宽度 - 间隙 × (列数 - 1)) ÷ 列数，间隙必须用
margin-right而非padding，否则影响 float 排列 - 每个子项加
style.cssText = "float: left; width: ${colWidth}px; margin-top: ${topOffset}px;"，topOffset来自当前列累计高度数组，用Math.min(...heights)找最短列
兼容性与性能的真实代价
在 Chrome 90+ 中，这种 JS + float 方案的 layout thrashing 极其明显：每次插入新项都触发全量重排，100 个子项可能造成 >200ms 的卡顿。移动端 Safari 对 float 的重绘优化更弱，且不支持 will-change: transform 来缓解。
立即学习“前端免费学习笔记（深入）”；
真正该用的方案是 column-count（适合文字流）或 display: grid 配合 grid-auto-flow: dense（需配合 grid-row-end 手动控制，仍非全自动），而生产环境强烈建议直接上 Masonry 库或 CSS container queries + grid 组合。float 瀑布流现在只剩两个用途：给 IE9 兜底，或者面试时被问到“如果不用 JS 怎么办”——答案其实是：你就不该用。
