CSS float 无法实现真正瀑布流，因其不感知列高、无法查找最短列；column-count 是零 JS 最佳替代；真瀑布流需 JS 动态计算最短列，现代项目应优先选用 CSS Grid 或 Masonry。
纯 CSS float 无法实现真正意义上的瀑布流效果——这不是写法问题，是布局模型本身的限制。
为什么 float 布局永远算不准“最短列”
float 的排列逻辑是文档流顺序 + 行内贴边，它根本不感知列高，也不支持“查完所有列再决定插哪儿”。比如三列中第 1 列只有 200px 高，第 2 列已到 800px，第 3 个元素不会落到第 1 列底部，而是紧贴第 2 列末尾继续向下排，形成明显断层。
常见错误现象包括：
- 视觉上列高严重不均，矮列顶部空一大片
- 加
clear: both在某列末尾，反而把其他列内容挤到下一行 - 用
:after { clear: both }只能撑开父容器高度，对齐毫无帮助
column-count 是最接近“零 JS 瀑布流”的可行方案
如果你的目标只是视觉上多栏错落、内容自动分段，column-count 是当前兼容性最好、最轻量的选择。它不是“模拟”，而是浏览器原生支持的多栏流式布局。
立即学习“前端免费学习笔记（深入）”；
关键配置要点：
- 容器必须设
height或max-height，否则只显示一列 - 子项加
break-inside: avoid防止卡片被截断（但部分 Safari 版本不认） - 避免给容器设
display: flex或align-items，这会直接禁用多列机制 -
column-fill: balance在 Chrome/Edge 有效，在 Firefox 需配合固定高度，Safari 17.4+ 才完整支持
真瀑布流必须靠 JS 找“最短列”，float 只能当摆设
如果业务要求每个新卡片必须精准插入当前最短列底部（例如无限滚动加载、点击排序），那 float 就只剩一个作用：让列容器并排。真正的布局逻辑必须由 JS 接管。
实操中容易踩的坑：
- 图片未加载完成时调用
getBoundingClientRect()，返回高度为 0，导致错位 - 没监听
img.onload或IntersectionObserver，懒加载图片后不重排 - 列容器宽度没包含
border和padding，计算列宽时总和超 100%，最后一列掉行 - 100+ 项时每加一项都遍历所有列找最小值，CPU 占用飙升；应改用
documentFragment批量插入 + 节流重排
现代项目请直接跳过 float，优先选 grid 或 Masonry
用 float 搭配 JS 实现瀑布流，本质是在废弃模型上打补丁：语义混乱、无障碍失效、响应式脆弱、维护成本高。2026 年真实项目里，你应该：
- 静态展示类场景（如图库预览）→ 直接用
column-count+break-inside: avoid - 交互复杂、需拖拽/排序/筛选 → 用
CSS Grid配合grid-row-end动态控制，或引入masonic（React）或vanilla-masonry - 小程序环境 → 优先用
column-count，iOS 微信基础库 2.25.0+ 已稳定支持
真正难的不是“怎么让元素落下去”，而是“怎么在图片异步加载、屏幕缩放、字体加载延迟、用户缩放页面这些真实变量下，始终让最短列判断不出错”。这个层面，float 连入场券都没有。
