column-count不是真正瀑布流，因其将容器内容视为连续文本流切片分栏，不感知子元素边界，无法按最短列动态分配完整子项；必须同时设置容器height/max-height、子项break-inside: avoid、子项不脱离文档流才视觉近似。
column-count 不能真正实现“瀑布流”，它只是把内容按列均匀切分，所有列高度强制拉齐——这是最常被误解的点。
为什么 column-count 看起来像瀑布流但实际不是
浏览器对 column-count 的实现是「块级内容流式分段」：把整个容器内容（如一段文字、一组 <div>）当成连续文本切片，每列获得大致等高的片段。它不感知子元素边界，也不会让每个子项完整落在某一列里。<p>常见错误现象：</p>
<ul>
<li>图片或卡片被硬生生从中间截断（尤其在 <code>break-inside: avoid 未生效时）
必须加的关键样式才能让 column-count 基本可用
若坚持用 column-count 模拟多列展示（非严格瀑布流），以下三项缺一不可：
立即学习“前端免费学习笔记（深入）”；
- 给容器设
column-count: 3（或具体数值）和column-gap: 20px - 给直接子元素（如
<article></article>或<div class="item">）加 <code>break-inside: avoid，防止被截断 - 容器需有明确高度或
height: auto且不限制子项高度；若设了固定height，超出部分会被截掉，且列高被强制均分
示例：
.masonry-like {
column-count: 3;
column-gap: 20px;
}
.masonry-like > * {
break-inside: avoid;
margin-bottom: 20px;
}
column-count 和 CSS Grid / Masonry 的本质区别
真正瀑布流（如 Pinterest）要求：每个子项完整落入某列，并按该列当前最短高度追加——这需要 layout engine 支持 item-level placement，而 column-count 属于 content-flow 分段，无 item 意识。
对比现实选择：
-
column-count：适合长文分栏、新闻摘要列表（子项高度相近、允许弱控制） - CSS Grid +
grid-template-rows: masonry（实验性，仅 Firefox 119+ 原生支持）：真瀑布流，但兼容性极差 - JavaScript 方案（如 Masonry.js、CSS Container Queries 配合 JS 计算）：可控性强，但增加运行时开销
目前最稳妥的“伪瀑布流”仍是 column-count + break-inside: avoid，但得接受它对子项高度差异敏感、无法精确控制列首尾对齐等限制。
真正想做响应式瀑布流时，column-count 只是视觉近似，别把它当 layout solution 用——它的设计目标从来就不是排列卡片。
