column-count仅能实现视觉近似瀑布流，非真Masonry布局；它按文档流顺序切片分栏，导致DOM与视觉顺序错位、卡片易被截断、交互失准，仅适用于纯展示、无交互、卡片高度相近的场景。
column-count 能快速搭出视觉接近瀑布流的布局，但不是真正意义上的瀑布流——它按文档流顺序切分内容，不保证列内元素连续，也不按高度自动错落。
为什么 column-count 在移动端“看起来像”瀑布流？
浏览器把容器当作文本段落处理：子元素被顺序切片、均匀分配到各列中。在卡片高度差异不大、数量较多时，视觉上容易形成错落感，尤其在窄屏下（如 iPhone 竖屏）列数少（column-count: 2），效果更明显。
- 适合场景：纯文字卡片、短资讯列表、头像+昵称等高度可控的轻量内容
- 不适合场景：高度差异大的图片卡片、需点击精准定位的交互区域（截断风险高）
- 必须加
break-inside: avoid，否则img或div可能被硬生生劈成两半 - iOS Safari 对
column-fill: balance支持极不稳定，别指望它让两列高度一致
column-count 的最小可用配置
以下 CSS 是移动端双栏可用的底线写法，已兼容 iOS 14+ 和主流 Android WebView：
.masonry-container {
column-count: 2;
column-gap: 8px;
}
.masonry-container > * {
break-inside: avoid;
margin-bottom: 8px;
}-
column-gap建议 ≤ 16px，过大易导致列宽不足、触发单列回退 - 容器必须有明确宽度（如
width: 100%）且不能是display: inline类型 - 子元素不能设
float或position: absolute，否则脱离文档流，break-inside失效 - 微信内置浏览器对
-webkit-column-count有残留兼容要求，建议保留前缀
常见错误：图片被截断、点击错位、顺序混乱
这些不是 bug，而是 columns 的设计本意 —— 它为排版服务，不是为卡片布局设计的。
立即学习“前端免费学习笔记（深入）”；
-
图片截断：没加
break-inside: avoid，或父容器用了overflow: hidden强制裁剪 - 点击错位：用户点的是右上角卡片，实际 DOM 顺序里它是第 5 个，JS 事件绑定按序号取值就偏了
- 顺序混乱：第 1 个卡片在左列顶部，第 2 个就在右列顶部，第 3 个又回到左列中部——时间倒序列表会显得“跳着读”
-
安卓低端机白屏：部分 Android 7–9 WebView 对
column-count渲染异常，加transform: translateZ(0)可触发硬件加速修复
真瀑布流需求下，column-count 只能当“临时方案”
如果你的业务要求卡片必须严格按顺序渲染（比如“最新发布”列表）、支持图片懒加载、或要响应式切换列数（2→3→4），column-count 就撑不住了。
-
grid-template-rows: masonry在 Chrome/Edge 116+ 可用，但 Safari 和 Firefox 完全不支持，上线前必须查 caniuse - 用
vanilla-masonry这类 JS 库反而更稳：它只操作top/left，不依赖 DOM 顺序，兼容性覆盖到 iOS 10+ - 最常被忽略的一点：
columns方案无法监听单个卡片的进入视口，IntersectionObserver在列布局下行为不可靠，懒加载得另找路子
