CSS Grid 的 grid-template-rows: masonry（Chrome/Edge 116+）是唯一原生响应式瀑布流方案，但属实验性且 Safari/Firefox 不支持；兼容性最佳的纯 CSS 方案是 column-count + break-inside: avoid，需注意直系子元素约束、Safari 兜底及末尾空白缺陷；复杂场景（如图片加载、拖拽排序）必须用 Masonry.js 等 JS 方案。
用 CSS Grid 实现真正响应式的瀑布流布局
原生 HTML5 不提供瀑布流布局能力，所谓“HTML5 布局代码”实际依赖 CSS。目前唯一无需 JS、能响应式断行且语义清晰的方案是 display: grid 配合 grid-template-rows: masonry（仅 Chrome 116+ / Edge 116+ 支持）。但要注意：它仍属实验性特性，grid-template-rows: masonry 在 Safari 和 Firefox 中完全不生效。
常见错误是直接套用旧教程里的 column-count 模拟法——它会导致元素内部文本折行错乱、无法控制单个子项对齐、且 break-inside: avoid 在部分场景下失效。
- 必须为容器设置
column-count或column-width，仅设其一即可；设两者时以column-width为优先参考 - 子项需加
break-inside: avoid，否则图片+文字块可能被硬生生截断在两列之间 - 容器高度不能设为
0或min-height: 0，否则列高塌陷，内容重叠 - 若子项含绝对定位元素（如 badge、close 按钮），需额外用
position: relative约束其父容器
用 column-count + break-inside 的兼容写法（支持 IE11+）
这是当前最稳妥的纯 CSS 瀑布流落地方式，适用于内容结构较固定、不要求严格等高对齐的卡片流（如博客列表、商品展示）。关键在于理解 column-count 是“列数建议值”，浏览器会按容器宽度自动调整实际列数，而非强制切分。
.masonry {
column-count: 3;
column-gap: 1rem;
}
.masonry > * {
break-inside: avoid;
margin-bottom: 1rem;
}注意：break-inside: avoid 在 Flex/Grid 容器内无效，所以子项必须是 .masonry 的**直系子元素**；若中间包了 <div class="wrapper">，就得把 <code>break-inside 移到该 wrapper 上。
立即学习“前端免费学习笔记（深入）”；
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
- Safari 对
break-inside支持较弱，可加-webkit-column-break-inside: avoid兜底 - 当子项高度差异极大（如混有 200px 和 800px 卡片），末尾可能出现大量空白列间隙，这是该方案固有缺陷，无法靠 CSS 修复
- 不支持子项 hover 时 z-index 提升——因为多列布局中，z-index 作用域被限制在当前列内
何时必须上 JavaScript 方案（Masonry.js / CSS Container Queries 配合 JS）
当你遇到这些情况，纯 CSS 已经撑不住：图片加载后高度变化导致列重排错位、需要拖拽排序、服务端渲染首屏要求像素级对齐、子项含视频/iframe 等异步尺寸元素。
推荐直接用 Masonry 库（v4.2+），它已放弃 jQuery 依赖，API 极简：
const elem = document.querySelector('.grid');
const msnry = new Masonry(elem, {
itemSelector: '.grid-item',
columnWidth: '.grid-sizer',
percentPosition: true
});-
columnWidth推荐用隐藏占位元素（.grid-sizer），比传数值更适应响应式缩放 - 图片加载完成必须显式调用
msnry.layout()，否则新图插入后位置错乱；可用imagesLoaded插件监听 - 服务端渲染时，避免在 SSR 阶段执行 JS 初始化，否则 hydrate 时出现 DOM 不匹配警告
- Vite/Next.js 环境下，务必用
useEffect或onMounted延迟到客户端执行
移动端适配中最容易被忽略的三个点
瀑布流在手机上崩得最突然，往往不是代码问题，而是 viewport 和缩放逻辑没理清。
-
meta name="viewport"必须含user-scalable=no？错。禁用缩放会导致 iOS 双击放大失效，反而影响可访问性；正确做法是保留缩放，但给卡片设max-width: 100vw防溢出 - 横屏切换时，
column-count不会自动重算——需监听resize事件并手动触发document.documentElement.style.columnCount = '2' - 微信内置浏览器对
column-gap渲染异常，实测在某些安卓机型上 gap 会变成 2px 固定值，绕过方式是改用padding-right模拟间隙
瀑布流没有银弹方案。CSS 列布局快但僵，JS 方案灵活却要扛加载与生命周期。选哪个，取决于你愿不愿意为「首屏白屏时间」多加 12KB 的 JS 脚本，以及设计师是否接受「最后一列底部留空」这个视觉妥协。
