column-count是当前唯一广泛支持、开箱即用的纯CSS瀑布流方案，它将容器视为多列文本流，需配合break-inside: avoid防截断，column-gap控间距，但列高平均且不支持优先填充控制。
现代 CSS 已经有多个可靠方案能替代基于 float 的瀑布流，且无需 JavaScript；但要注意：**column-count 是目前唯一已广泛支持、开箱即用的纯 CSS 瀑布流方案，grid-lanes 尚未进入正式标准，仅在部分浏览器实验性支持。**
column-count 是当前最稳的纯 CSS 瀑布流方案
它把容器当作“多列文本流”，内容按列自动分段填充，天然符合瀑布流视觉逻辑。
- 必须配合
break-inside: avoid（或page-break-inside: avoid）防止卡片被截断 -
column-gap控制列间距，不能用gap（该属性对 column 布局无效） - 不支持子项单独设置高度控制“哪一列优先填充”，所有列高度趋于平均——这是和 JS 瀑布流的本质区别
- 响应式只需改
column-count或用column-width+max-width组合，比 float 媒体查询简洁得多
display: grid + grid-auto-flow: dense 不是真正瀑布流
虽然常被误称为“CSS Grid 瀑布流”，但它只是按行/列顺序填空，并不会像瀑布流那样“找最短列插入”。实际效果更接近错位网格，而非参差高度的自然下落。
-
grid-template-columns: repeat(auto-fill, minmax(250px, 1fr))只定义列宽，不触发瀑布行为 -
grid-auto-flow: dense仅用于填补空缺，无法让新项主动选择“最短轨道” - 若卡片高度差异大，会出现大量空白间隙，视觉上不像传统瀑布流
- 真要模拟，得靠 JS 计算每列高度并动态插入——又回到老路
grid-lanes 是未来方向，但今天不能用
它确实是规范中定义的“原生瀑布流”，语法简洁，语义明确，但截至 2026 年 6 月，display: grid-lanes 仍处于 CSSWG 工作草案阶段，Chrome/Firefox/Safari 均未实装稳定版本。
立即学习“前端免费学习笔记（深入）”；
- 某些开发者看到的“演示效果”，实际是通过 Chromium 实验标志（
--enable-blink-features=CSSGridLanes）手动开启的非默认行为 - MDN 和 CanIUse 当前均无该属性支持数据，上线项目中写死
grid-lanes会导致整个容器渲染失败（回退为display: block） - 别被“三行代码实现瀑布流”的宣传误导——那不是生产环境可用的方案
flex 嵌套 + JS 计算仍是过渡期常见折中
当 column-count 的平均列高不符合设计要求，又不愿引入完整 JS 库时，有人用 Flex 模拟“伪瀑布流”：外层横向 display: flex，内层每列纵向 display: flex; flex-direction: column，再用 JS 把卡片依次塞入当前最短列。
- 这种方案可控性强，但已脱离“纯 CSS”范畴，JS 逻辑需处理窗口 resize、异步加载、无障碍焦点顺序等细节
- 注意避免在 Flex 容器中给子项设
float——该属性会被忽略，且可能干扰flex-basis计算 - 若仅需简单两列错落，
column-count: 2配合break-inside几乎零成本，远优于手写 JS
真正容易被忽略的是：瀑布流是否真的需要“严格高度错落”？很多所谓“必须瀑布流”的场景，其实用 grid 的自适应卡片网格（grid-template-columns: repeat(auto-fill, minmax(280px, 1fr))）+ gap 更稳定、更易访问、更利于 SEO。视觉上的“参差感”，往往靠卡片内部图片比例或文字行数差异就能达成，不必强求布局引擎去模拟物理下落。
