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>，语义断裂 - 卡片里有
<button>，tab 键焦点跳到第 2 列顶部，再回到第 1 列中间 - 打印样式下变成单列长条，无法控制分页位置
能缓解但不能根治的做法：
- 容器设
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 轮询或事件兜底。
