CSS Grid 无法真正实现瀑布流，grid-auto-flow: dense仅回填固定高度空隙，不支持动态列高；真瀑布流需JS计算列高或使用grid-template-rows: masonry（Chrome 116+实验性支持），但Safari/Firefox仍不兼容。
用 CSS Grid 实现响应式瀑布流，避开 column-count 的断裂陷阱
现代浏览器中，display: grid 配合 grid-template-columns: masonry 尚未被广泛支持（截至 2024 年底仅 Chrome 116+ 启用实验性 flag），所以真正在生产环境稳定可用的“CSS 瀑布流”，其实是靠 column-count + break-inside: avoid 拼出来的。但它有个致命问题：图片或卡片高度突变时，内容会在列内被硬生生截断，出现元素劈成两半、文字断行错位等现象。
真正靠谱的做法是主动放弃纯 CSS 方案，改用 JavaScript 控制列高平衡。但如果你坚持用 CSS，必须加这几条：
-
column-count设为具体数字（如3），不要用auto - 每个子项必须设
break-inside: avoid（注意 Safari 要加-webkit-column-break-inside: avoid） - 父容器禁用
overflow: hidden，否则截断内容不可见 - 避免子项内使用
position: absolute或transform，它们会脱离列流，导致布局错乱
用 Masonry API（Chrome 116+）快速启用原生瀑布流
Chrome 116 起默认开启 display: grid 的 masonry 布局（需开启 chrome://flags/#enable-experimental-web-platform-features），它才是语义正确、不截断、可响应的真瀑布流。
用法极简：
立即学习“前端免费学习笔记（深入）”；
.container {
display: grid;
grid-template-columns: repeat(3, 1fr);
grid-auto-flow: column;
grid-template-rows: masonry;
}
注意三点：
-
grid-auto-flow: column必须显式声明，否则按行填充，不是瀑布流 -
grid-template-rows: masonry是核心，不能写成grid-template-rows: masonry 1fr这类错误组合 - 目前仅 Chrome 支持，Firefox/Safari 仍回退到
column-count方案，需用@supports检测并降级
用 muuri 库做兼容性最强的 JS 瀑布流
当项目需要 IE11 支持或高度定制（拖拽排序、动画、过滤），muuri 是目前最轻量（~15KB gzip）、API 最干净的方案。它不依赖框架，纯原生 DOM 操作。
初始化只需三步：
- 给容器加
data-muuri属性或直接传 DOM 元素 - 每个子项必须有固定 class（如
.item），且不能用display: contents - 调用
new Muuri('.grid', { layout: { fillGaps: true } })
常见坑：
- 子项初始必须有明确高度（哪怕用
min-height: 200px占位），否则muuri计算列高失败 - 动态插入新元素后，必须调用
grid.add(el)，不能只appendChild - 图片加载完成前就渲染，会导致高度塌陷——得监听
img.onload后调用grid.refreshItems().layout()
为什么不用 Isotope 或 Masonry.js？
Isotope 功能全但体积大（~70KB），且依赖 jQuery；Masonry.js 已停止维护（最后更新 2021），对 Flex/Grid 混合布局支持差，遇到 aspect-ratio 或 contain-intrinsic-size 容易误判高度。
更实际的问题是：这两个库默认把子项用 position: absolute 定位，一旦页面缩放、字体大小变更或触发强制重排，位置就偏移，debug 成本远高于 muuri。
如果只是静态展示，用 column-count + break-inside 足够；要交互能力，muuri 是当前最省心的选择。别在兼容性上赌浏览器的 masonry 支持进度——它连 Safari 技术预览版都还没进。
