column-count 瀑布流错乱主因是其将内容当文本流切分，不感知子元素边界，break-inside: avoid 兼容性差且对 flex/grid 无效；grid 虽可控但无原生 masonry，需显式布局或 JS 补足。
column-count 实现瀑布流时内容会错乱，原因在哪
用 column-count 做瀑布流，最常遇到的是图片/卡片高度不一导致的“断行错位”——比如第二列顶部空着一大块，第三列内容却提前挤上去。这不是渲染 bug，而是 column 布局本质：它把整块内容当作文本流切分，不感知子元素边界，break-inside: avoid 仅在支持度好的浏览器中生效，且对 flex/grid 子项无效。
实操建议：
- 只用于纯文字或高度一致的卡片（如统一
height: 200px） - 必须加
column-gap和column-fill: auto防止列高严重不均 - IE10+ 支持
column-count，但 Safari 对break-inside的处理仍有偏差
grid 实现真正可控的瀑布流要绕开 auto-fit
CSS Grid 本身不原生支持“按内容高度自动分配到最短列”的瀑布流（那是 Masonry 的事），但可用 grid-template-rows: masonry（实验性）或更稳妥的多列固定轨道方案。目前稳定可用的是「显式定义列数 + 每项指定 grid-row」，或配合 JS 计算行起始位置。
纯 CSS 可行做法（无需 JS）：
立即学习“前端免费学习笔记（深入）”；
- 设
display: grid+grid-template-columns: repeat(3, 1fr) - 每项用
grid-column: 1/grid-column: 2手动分配列（适合静态内容） - 若需动态填充，必须用
grid-auto-flow: dense+ 显式grid-row-start，否则项会按 DOM 顺序逐行填满，失去瀑布效果
注意：grid-template-rows: masonry 目前仅 Chrome 116+ 与 Safari 17.4+ 支持，且需加 @supports (grid-template-rows: masonry) 守卫。
对比性能：column-count 更轻量，grid 更可控但重绘成本高
column-count 是浏览器文本排版引擎直接处理的，滚动时几乎无重排；而 Grid 瀑布流（尤其带 grid-auto-flow: dense）在内容增删时可能触发整网格重计算，长列表下帧率易抖动。
选型参考：
- 内容少、更新不频繁、允许弱语义（如博客归档页）→ 用
column-count+break-inside: avoid - 需要点击排序、拖拽重排、响应式列数变化 → 必须上 JS 驱动的 Masonry 库（如
masonic或react-virtualized） - 仅需三列静态展示且要严格对齐 → Grid 显式列 + 手动
grid-column最稳
容易被忽略的兼容性断点：Safari 对 column-gap 的解析差异
Safari 15.4–16.3 在 Flex 容器内嵌套 column-count 时，column-gap 会被忽略，表现为列紧贴无间隔。这不是 bug，是 Safari 将 Flex 子项的 column 布局视为“匿名块”，gap 不继承。
绕过方式：
- 外层不用
display: flex，改用display: block或 Grid 包裹 - 给 column 容器加
margin-inline: calc(var(--gap) / -2)+ 子项padding-inline: calc(var(--gap) / 2)模拟 gap - 检测 Safari：
@supports (-webkit-appearance: none) and (not (grid-template-rows: masonry))
真瀑布流没有纯 CSS 银弹。column-count 是妥协方案，grid 是可控起点，而生产环境里，90% 的“瀑布流”最终都悄悄引入了 JS 来兜底高度计算和重排逻辑。
