移动端双栏瀑布流用column-count最简单但内容顺序是“从上到下、再换列”，视觉割裂；Grid真瀑布流需grid-auto-flow:column，但Safari兼容差；推荐column-count+JS补救顺序，兼顾兼容与可控性。
移动端双栏瀑布流用 column-count 最简单，但内容顺序是“从上到下、再换列”
这不是你直觉里“左栏先填满、右栏再填满”的瀑布流，而是把整个容器当作文本段落来分栏：浏览器会把所有子元素按文档流顺序切片，均匀分配到各列中。这意味着第1个卡片可能在左栏顶部，第2个就在右栏顶部，第3个又回到左栏中部——对图文卡片类内容来说，视觉割裂感强。
实操建议：
- 只适用于纯文字块或高度差异小的卡片（比如短资讯列表），且不依赖卡片间逻辑顺序
- 必须设
column-gap和break-inside: avoid，否则卡片被截断：article { column-count: 2; column-gap: 16px; }<br>article > * { break-inside: avoid; } - iOS Safari 对
column-fill: balance支持不稳定，别依赖它强制均等填充
Grid 实现“真瀑布流”要放弃 grid-template-columns，改用 grid-auto-flow: column
很多人误以为两列 Grid 就是瀑布流，结果写成 grid-template-columns: 1fr 1fr —— 这只是等宽分栏，每行固定两个子项，完全不是瀑布流效果。
真正可行的 Grid 瀑布流写法是：
立即学习“前端免费学习笔记（深入）”；
- 容器设
display: grid+grid-auto-flow: column，让子项按列优先顺序填入 - 用
grid-auto-columns控制单列宽度（如minmax(300px, 1fr)），并配合grid-auto-rows: 10px（占位用，实际由内容撑开） - 必须加
grid-row-end: -1或类似 hack 让每项自动跨行，否则列内项会堆叠在第一行
但要注意：这个方案在 Safari 上有严重兼容问题，grid-auto-flow: column 在 iOS 15.4 之前几乎不可用，且无法与 gap 完美协同。
实际项目中更推荐 column-count + JS 补救顺序问题
如果业务要求卡片顺序必须连贯（比如按时间倒序排列），又不想引入 Masonry 库，可以妥协处理：
- 用
column-count: 2渲染，视觉上接近瀑布流 - 用 JS 把 DOM 节点按“列优先索引”重排一次：算出总高、预估每列应有多少项、手动移动节点位置
- 或者更轻量：给每个卡片加
data-index，CSS 用:nth-child(odd)/:nth-child(even)做基础分栏，再靠 JS 动态调整order值模拟瀑布流
这种混合方案在微信内置浏览器和主流 Android WebView 中表现稳定，比纯 CSS Grid 更可控。
别忽略容器高度和滚动性能
无论用哪种方式，瀑布流容器都必须有明确高度或 max-height 才能触发列布局，否则 column-count 会退化为单列；而 Grid 方案若不限制容器高度，可能造成无限拉伸。
性能方面：
-
column-count触发重排成本低，适合长列表（上千项） - Grid 方案在子项数量多时，浏览器计算列位置耗时明显，尤其在低端安卓机上易掉帧
- 所有方案都要避免在瀑布流容器内使用
position: sticky或复杂阴影，这会让合成层管理失效
真实场景里，多数“双栏瀑布流”需求其实不需要严格物理对齐，适当留白+弹性宽度反而更容错。别为了“看起来像瀑布流”强行套技术方案。
