column-count 实现的是伪瀑布流，需设容器高度、避免卡片截断、慎用margin、响应式优先用column-width。
column-count 能做出视觉上接近瀑布流的文章列表，但不是真 Masonry —— 它按内容流顺序切分，不找最短列；能用，前提是接受它的行为边界和限制条件。
为什么文章卡片常被截断在两列之间
根本原因是 column-count 把整个容器当作文本段落处理，遇到没加防护的 <article></article> 或 <div class="post">，浏览器会直接在中间“折行”。比如一张带标题、摘要、图片的卡片，可能标题在左列、图片掉进右列底部。
<ul>
<li>必须给每个文章项（如 <code>.post、article）加 break-inside: avoid
-webkit-column-break-inside: avoid，Firefox 有时要 -moz-break-inside: avoid
page-break-inside: avoid 对打印有效，页面渲染中基本无效，别依赖display: flex 或 grid，只要最外层容器设了 break-inside: avoid，子元素不用重复设容器高度不设，column-count 就等于没写
这是最常被忽略的硬性前提：没有 height 或 max-height，浏览器认为“空间无限”，自动退化为单列。哪怕你写了 column-count: 3，也只显示一列。
- 推荐用
max-height: 80vh或具体像素值（如max-height: 1200px），避免撑爆视口 - 别用
min-height替代 —— 它不触发分栏逻辑 - 移动端需注意：iOS Safari 对无高度容器的 fallback 行为更激进，几乎必然单列
- 若内容动态加载，JS 插入新项后需手动触发重排（如
container.style.maxHeight = container.style.maxHeight）
column-gap 和 margin 混用会导致列高失衡
用 margin-bottom 模拟卡片间距，会让浏览器误判子项实际高度，干扰“哪列最短”的计算逻辑，最终出现一列堆满、另一列大片留白。
- 统一用
column-gap: 24px控制列间空隙，不要给.post加margin-bottom -
column-gap值建议用px，避开 Safari 对rem或百分比的解析偏差 - 图片必须设
width: 100%+height: auto，否则原始尺寸会撑破列宽，引发错位 - 如果卡片含异步加载的图片，需监听
load事件后调用container.style.columnCount = container.style.columnCount强制重算
响应式列数切换别只靠媒体查询改 column-count
单纯写 @media (max-width: 768px) { .posts { column-count: 2; } } 在小屏下容易导致列过窄、文字挤成一团，或最后一列严重留白。
- 优先考虑用
column-width: 300px替代固定列数，让浏览器自动算列数（至少 1 列） - 若必须控列数，搭配
column-gap和明确的最小宽度约束，例如：@media (max-width: 480px) { .posts { column-count: 1; width: 100%; } } - 横屏旋转时，
column-count不会自动更新 —— 如需实时响应，得监听resize并 JS 重设 - 微信内置浏览器和部分 Android WebView 对
column-fill: balance支持差，建议显式设column-fill: auto保顺序
真正难搞的不是怎么写这三行 CSS，而是图片加载延迟、字体渲染差异、动态插入内容这三件事 —— 它们都会让列高计算瞬间失效，且没有任何回调可监听。上线前务必在 iOS Safari 和微信里实测滚动过程中的卡片完整性。
