column-count 仅实现线性分栏而非 Masonry 瀑布流，DOM 顺序与视觉顺序不一致；需三行关键 CSS（column-gap、break-inside: avoid、max-height）并注意移动端适配陷阱，复杂场景应改用 JS 方案。
column-count 能快速实现视觉上接近瀑布流的效果，但不是 Masonry 风格的“按高度找最短列”——它把容器当作文本流切分，内容顺序是线性填充、跨列分配，DOM 顺序 ≠ 视觉顺序。适合纯展示、无交互依赖、卡片高度差异不大的场景。
为什么 column-count 常被误用为“真瀑布流”
很多人以为设了 column-count: 3 就能像 Pinterest 那样自动把新卡片塞进最短列，实际浏览器只是按文档流把所有子项从上到下“切片”，平均分到各列里。结果就是：第 1 个卡片在左栏顶部，第 2 个直接跳去右栏顶部，第 3 个又回到左栏中部——逻辑顺序被打乱。
常见错误现象包括：
-
img被拦腰截断（没加break-inside: avoid） - 点击区域偏移（视觉位置和 DOM 顺序不一致）
- 屏幕阅读器读序错乱
- 带
position: sticky的标题吸附失效
必须写的三行 CSS 才能跑通 column-count
缺一不可，否则大概率渲染异常：
立即学习“前端免费学习笔记（深入）”；
- 容器必须设
column-gap（不能依赖默认值；iOS Safari 默认1em，容易挤爆） - 每个子项必须加
break-inside: avoid（防止被切开；Safari 15.4+ 才稳定支持，旧版需加-webkit-column-break-inside: avoid） - 容器必须有
max-height或height（否则列高无限拉长，只显示一列）
示例：
.waterfall {
column-count: 3;
column-gap: 16px;
max-height: 70vh; /* 关键！ */
}
<p>.waterfall > .item {
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
遇到以下任一条件，就别硬撑了：
- 卡片之间有强逻辑顺序（比如时间倒序、步骤引导），不能接受 DOM 和视觉顺序错位
- 需要支持老 Android WebView（
column-count在部分 Android 4.x 内核中行为异常） - 卡片内含复杂交互（如拖拽、hover 展开、sticky 标题）
- 要求列高严格均衡（
column-fill: balance在 Safari 上支持不稳定）
真正可控的瀑布流目前仍需 JS 补足，column-count 的“轻量”是有明确边界的——它只负责分栏，不负责理解内容语义。
