column-count 能实现视觉上接近两列瀑布流的效果，但不是真正按高度找最短列的瀑布流——它按内容流顺序“切片分栏”，卡片 DOM 顺序和视觉位置不一致，仅适合纯展示、无交互依赖、卡片高度差异小的场景。
直接说结论：column-count 能实现视觉上接近两列瀑布流的效果，但不是真正按高度找最短列的瀑布流——它按内容流顺序“切片分栏”，卡片 DOM 顺序和视觉位置不一致，**仅适合纯展示、无交互依赖、卡片高度差异小的场景**。
为什么 column-count: 2 看起来像瀑布流，实际却很割裂
浏览器把整个容器当作文本段落处理：第 1 个卡片进左栏顶部，第 2 个就直接去右栏顶部，第 3 个又回左栏中部……这不是“左栏填满再填右栏”，而是“平均切片分配”。对图文卡片来说，时间倒序或逻辑关联的内容会严重错位。
常见错误现象包括：
- 点击第 3 张卡片，实际触发的是视觉上在右栏第二位的第 2 张卡片（DOM 顺序 vs 视觉顺序错位）
- 屏幕阅读器按 DOM 顺序读，用户听到的是“卡片1→卡片2→卡片3”，但看到的是“卡片1→卡片3→卡片2”
- 带
position: sticky的标题在多列中失效，或吸附位置偏移
column-count 必须配的三项 CSS 规则
缺一不可，否则大概率出问题：
立即学习“前端免费学习笔记（深入）”；
- 容器必须设
column-gap（不能靠默认值，iOS Safari 默认是1em，容易挤爆） - 每个卡片必须加
break-inside: avoid（防止卡片被拦腰截断；注意 Safari 15.4+ 才稳定支持） - 容器必须有显式
height或max-height（否则列高无限拉长，只显示一列）
示例写法：
.card-list {
column-count: 2;
column-gap: 16px;
max-height: 70vh; /* 关键！不能省 */
}
.card-list > .card {
break-inside: avoid;
margin-bottom: 16px; /* 避免列末尾留白错位 */
}移动端适配中最容易被忽略的三个坑
这些不是边缘 case，而是上线后高频报障点：
- 横屏旋转时，
column-count不会自动重算列数——得监听resize事件，手动切换值，或改用column-width+min-width组合（但列数不可控） - 图片异步加载完成前高度为 0，导致列高预估错误，后续卡片错位；需配合
aspect-ratio或padding-top占位，确保初始宽高比稳定 - 懒加载失效：基于
window.scrollY的方案在多列容器里完全不可用，必须用IntersectionObserver监听每个卡片自身，且rootMargin别设太大负值（iOS Safari 对负 margin 处理不稳定）
什么时候该果断放弃 column-count？
遇到以下任一条件，就别硬撑了：
- 卡片需要点击跳转、带表单、有拖拽或 hover 交互
- SEO 或无障碍要求 DOM 顺序 = 视觉顺序（比如新闻列表按发布时间倒序）
- 卡片高度差异极大（如混排文字摘要 + 长图 + 视频封面）
- 要支持 iOS 15.3 及更早版本（
break-inside: avoid在多列中表现不可靠）
此时更稳的选择是：小屏用 display: grid + grid-template-columns: repeat(auto-fill, minmax(300px, 1fr)) 做等高网格，大屏再切 JS Masonry；或者直接上轻量级 JS 补救方案——用 column-count 渲染，再用 JS 按列高重排 DOM 节点顺序。后者在微信 WebView 和主流 Android 上表现远比纯 Grid column 流更可控。
