chrome 116+/edge 116+原生支持grid-template-rows: masonry，需配合display: grid、grid-template-columns及@supports降级，图片设width:100%;height:auto防塌陷，禁用height/min-height以保障动态填充。

用 grid-template-rows: masonry 让浏览器自动对齐高度差

Chrome 116+ 和 Edge 116+ 已原生支持 grid-template-rows: masonry，它不依赖 JS 计算、不监听图片加载、不触发重排，卡片高度差异直接由布局引擎处理。这是目前最平滑的方案。

实操建议：

• 容器设 display: grid + grid-template-rows: masonry，列数交给 grid-template-columns 控制（如 repeat(auto-fill, minmax(300px, 1fr)))）
• 必须配合 @supports (grid-template-rows: masonry) 包一层，否则旧浏览器会直接忽略整条规则
• 卡片内图片加 width: 100%; height: auto;，避免高度塌陷导致列错位
• 不要给卡片设 height 或 min-height，否则破坏 Masonry 的动态填充逻辑

降级 fallback 到 column-count 时怎么避免顺序错乱

column-count 是兼容性最好的纯 CSS 方案，但它按文档流切分内容，视觉顺序 ≠ DOM 顺序——这对 SEO、屏幕阅读器和键盘 tab 都是硬伤。

常见错误现象：

• 用屏幕阅读器读取时，第 1 列底部卡片可能来自第 7 个 <div>，语义断裂 <li>卡片里有 <code><button></button>，tab 键焦点跳到第 2 列顶部，再回到第 1 列中间
• 打印样式下变成单列长条，无法控制分页位置

能缓解但不能根治的做法：


Wechat HTML Publisher
直接上传HTML富文本到微信公众号草稿箱。支持完整的HTML格式,无需Markdown转换。
下载
• 容器设 column-count: 3（或用 column-width: 300px 响应式）
• 每个卡片加 break-inside: avoid，Firefox 还要补 page-break-inside: avoid
• 所有卡片必须是块级元素，不能用 float、inline-block 或绝对定位
• 避免在卡片内嵌套 flex/grid 容器——它们会干扰列流计算

JS 方案里图片没加载完就渲染，卡片重叠怎么办

React/Vue 项目若用 react-virtualized-masonry 或 v-masonry，核心问题是：懒加载图片返回前，JS 拿不到真实高度，导致布局错位。

关键动作不是“等所有图加载完”，而是“监听单张图加载完成即更新局部”：

• 给卡片内 <img> 绑定 onLoad，触发后调用库的 layout() 或 updateItemHeight(id, height)
• 服务端渲染（SSR）首屏必须配 fallback 样式，比如先用 display: grid 渲染，等 JS 加载后再切换 Masonry
• 滚动加载新卡片时，别调 layoutAll()，改用增量更新——记录已渲染项的 offsetTop 和 height，只重算新增部分
• 慎用 object-fit: cover + aspect-ratio：虽然能防塌陷，但若宽高比与实际图片不符，仍会导致 JS 误判高度

为什么 flex-wrap: wrap 和 grid-auto-flow: dense 都不是真瀑布流

这两个方案常被误当作替代，但它们根本机制不同：flex 按行填满，grid 按轨道坐标分配，都不模拟“列优先、找最低空位”的瀑布逻辑。

典型表现：

• flex-wrap: wrap 下，短卡片不会上浮填补前一列顶部空隙，而是留在本行末尾，留下明显白边
• grid-auto-flow: column 看似按列排列，但元素仍严格按 DOM 顺序垂直堆叠，不响应高度变化——第 1 列第 3 个卡片可能比第 2 列第 1 个还高，视觉断层
• 两者都无法解决“异步加载后高度突变引发的重排抖动”，而 Masonry 布局天然规避这点

真正难处理的不是多高，而是“高度何时确定”——图片加载、字体加载、动态内容注入，都让高度成为运行时变量。Masonry 的价值不在视觉效果，而在把高度不确定性交由浏览器原生处理，而不是靠 JS 轮询或事件兜底。