column-count是最快上线的纯CSS移动端瀑布流方案，但非真Masonry——它按DOM顺序切片分栏而非按列高自动填充；浏览器将容器视作文本段落，子元素被均匀分配至各列，仅在卡片高度相近时视觉错落感明显。
纯 CSS 实现移动端瀑布流，column-count 是最快能上线的方案，但不是真瀑布流——它不按列内高度排序填入，只按 DOM 顺序切片分栏；真正按高度自动错落的 Masonry 效果，目前仅靠 CSS 还做不到全平台兼容。
为什么 column-count 在移动端“看起来像”瀑布流
浏览器把容器当作文本段落处理：子元素被顺序切片、均匀分配到各列中。卡片高度差异不大时（比如短图文、头像+昵称），在窄屏（column-count: 2）下视觉错落感明显。
- 适合场景：纯展示、无交互、卡片高度相近（标准差
- 不适合场景：图片卡片（易被
break-inside: avoid失效截断）、需点击精准定位的区域、时间倒序列表（第1项可能在右栏顶部） - 必须加
break-inside: avoid，否则img或div可能被劈成两半 - iOS Safari 对
column-fill: balance支持极不稳定，别指望两列等高
grid-auto-flow: column 能实现真瀑布流吗
能，但几乎不能用在真实项目里。
- 正确写法是：
display: grid+grid-auto-flow: column+grid-auto-columns: minmax(300px, 1fr)，而非grid-template-columns: 1fr 1fr（那是等宽分栏，不是瀑布流） - 必须配合
grid-row-end: -1或类似 hack 让每项自动跨行，否则所有项堆在第一行 - Safari 在 iOS 15.4 之前基本不支持
grid-auto-flow: column；iOS 16+ 虽支持，但gap渲染异常、滚动卡顿频发 - 微信内置浏览器（X5 内核）至今未透出稳定支持信号
小程序和 WebView 中怎么选
小程序（微信 2.10.0+）和主流 Android WebView 可安全用 column-count，但要注意三处硬限制：
立即学习“前端免费学习笔记（深入）”；
- 容器必须有明确宽度（如
width: 100%），且不能是display: inline类型 - 子元素不能设
float或position: absolute，否则脱离文档流，break-inside: avoid失效 - 部分 Android 7–9 WebView 会白屏，加
transform: translateZ(0)触发硬件加速可修复 - 微信小程序建议保留
-webkit-column-count前缀，避免旧版兼容问题
真瀑布流需求下，column-count 只能当临时方案
如果业务强依赖卡片顺序连贯（比如评论按时间倒序）、或卡片高度差异大（封面图 1:1 vs 街拍 9:16），column-count 的 DOM/视觉错位就会暴露——这时 JS 补救比换方案更实际：用 column-count: 2 渲染基础布局，再通过计算列高、重排 DOM 节点或动态设置 order 值来修正视觉顺序。这不是妥协，而是当前生态下最可控的落地路径。
