column-count: 2 是唯一稳定、无需 JS、真正自适应列高且跨浏览器可用的双栏瀑布流方案，因其按内容顺序自然分列并平衡列高，而 grid 等方案强制等高违背瀑布流本质。
纯 CSS 实现双栏瀑布流，column-count: 2 是目前唯一稳定、无需 JS、能真正自适应列高且跨浏览器可用的方案。其他看似“更现代”的方式（比如 display: grid 配 grid-auto-rows）实际会强制等高，根本不是瀑布流。
为什么 column-count 是双栏瀑布流的唯一靠谱选择
很多人试过 display: grid + grid-template-columns: repeat(2, 1fr)，再加 grid-auto-rows: 200px，结果发现所有卡片底部留白巨大，或者长卡片直接溢出容器——这是因为 grid-auto-rows 给的是**每行轨道的固定高度**，不是每列的自适应高度。瀑布流的本质是“列高不等、内容自然断行”，而 Grid 的隐式行机制天生违背这点。
column-count: 2 则完全不同：它把容器当作一个「多列文本流」，浏览器按内容顺序从上到下填满第一列，再填第二列，自动平衡列高。卡片高度完全由自身内容决定，视觉上就是错落的双栏瀑布流。
- 兼容性好：
column-count在 Chrome 50+、Firefox 13+、Safari 10.1+、Edge 79+ 均原生支持，无前缀 - 无需 JS 计算位置，不监听图片加载，不处理 resize，布局开销极低
- 响应式友好：配合
@media可轻松切为column-count: 1（单栏）或3（三栏） - 注意：子元素必须是普通块级流内元素，不能是
display: grid或display: flex容器，否则会破坏列断行为
break-inside: avoid 必须加，否则卡片会被劈成两半
默认情况下，浏览器在分列时可能把一个高卡片从中间切断——比如标题在第一列，图片和描述跑到第二列。这是多列布局最常被吐槽的 Bug，但只需一行 CSS 就能解决：
立即学习“前端免费学习笔记（深入）”；
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
.waterfall > * {
break-inside: avoid;
margin-bottom: 16px;
}其中 break-inside: avoid 告诉浏览器“别在这儿断开”，margin-bottom 提供列内垂直间距。注意这个样式必须作用在**直接子元素**上（即每个卡片），且不能用 display: contents 或 transform 等会创建新格式化上下文的属性干扰它。
- 不要写成
page-break-inside: avoid（已废弃） - 如果卡片内部用了
flex或grid，确保其子项没触发新的分页/分列断点 - 部分旧版 Safari 对
break-inside支持不稳定，可加-webkit-column-break-inside: avoid作降级
双栏瀑布流与响应式断点怎么配
双栏不是一成不变的。小屏手机上强行双栏会导致卡片过窄、文字换行频繁；大屏则可扩展为三栏甚至四栏。用媒体查询控制 column-count 最直接：
.waterfall {
column-count: 1;
}
@media (min-width: 640px) {
.waterfall { column-count: 2; }
}
@media (min-width: 1024px) {
.waterfall { column-count: 3; }
}这里的关键是：断点值要基于**卡片最小可读宽度**来定，而不是设备尺寸。例如卡片含 16px 正文，最小安全宽度约 320px，那么双栏起始点设为 640px（2×320）更合理。若卡片含大图或宽表格，断点就得后移。
- 避免用
max-width做断点，它无法反映内容实际渲染宽度 - 不要在同一个媒体查询里混用
column-count和display: grid，二者机制冲突 - 测试时务必在真机或模拟真实 DPR 的设备上查看，高 DPR 下字体渲染宽度可能影响断点触发
真正难的不是写那几行 CSS，而是理解「瀑布流」不是视觉错觉，而是内容流的自然断裂。一旦你开始用 JS 手动计算 top/left 或 grid-row-end，就等于放弃了浏览器原生布局能力——而 column-count 这个被低估的属性，至今仍是双栏瀑布流最轻、最稳、最接近“设置即生效”的解法。
