根本原因在于浏览器不计算前一张卡片底部位置，top需动态读取offsetheight与offsettop累加计算，硬编码像素值或忽略父容器position:relative会导致错位。
用 position: absolute 做瀑布流，为什么算不准 top？
根本原因在于：浏览器不帮你算“前一张卡片的底部位置”。你写 top: 200px，它就真只认这个数；一旦某张卡片高度动态变化（比如图片加载后撑开、文字展开），后续所有 top 值全错位。
常见错误现象：top 全是固定像素值，响应式缩放后堆叠重叠或留白；加了 margin-top 混合使用，但父容器没设 position: relative，结果卡片飞到视口左上角；或者用了 z-index 手动排序，反而盖错了层。
- 必须给父容器设
position: relative，否则absolute卡片会相对于 viewport 定位 -
top应基于前一张的 bottom + 偏移，不能硬编码 —— 实际得靠 JS 动态读取offsetHeight+offsetTop累加计算 - 如果非要用 CSS 控制，可用自定义属性配合
calc()，例如：top: calc(var(--base) + var(--index) * 12px)，但前提是--index能被 JS 注入或 CSS @property 控制（兼容性有限）
grid-auto-flow: dense 真的能模拟瀑布流吗？
不能。它只是“紧凑填充”，不是“按列高度平衡分布”。grid 是格子化模型，每张卡片占一个网格单元，高度由内容决定，但列高不会自动拉齐 —— 最终效果是顶部对齐、底部参差，视觉上像“阶梯”，而非传统瀑布流那种“各列底部尽量齐平”的流动感。
使用场景：适合卡片宽度一致、高度差异不大、且需要强响应式换列（如 minmax(250px, 1fr)）的列表页。不适合博客、图集这类高度剧烈波动的内容流。
-
grid-template-columns: repeat(auto-fill, minmax(250px, 1fr))控制列宽，但列数由容器宽度推导，不是固定列高分配 -
grid-auto-flow: dense仅影响空缺格子是否被跳过，不改变卡片在列中的垂直顺序 - 若卡片内有异步加载内容（如懒加载图片），高度突变会导致下方卡片突然下坠，无回填机制
为什么 column-count + break-inside: avoid 是目前最稳的纯 CSS 瀑布流方案？
因为它是唯一被浏览器原生支持、专为“内容流式分栏”设计的机制。浏览器内部会测量每张卡片高度，按列高大致均分内容，自动避免跨列断裂 —— 这正是瀑布流的核心诉求。
容易踩的坑集中在细节控制：卡片被劈开、右边留白、小屏退化失败、底部空隙明显。
- 必须加
break-inside: avoid（旧版 Safari 需-webkit-column-break-inside: avoid） -
column-gap设固定值（如1rem），别用百分比，否则缩放时间隙浮动导致列宽重算错乱 - 容器左右
padding设为column-gap / 2，可对齐首尾列边缘 - 小屏务必加
@media (max-width: 480px) { column-count: 1; }，否则浏览器可能把column-width: 300px当成无效值直接忽略
什么时候该放弃纯 CSS，转向 JS 驱动的 Masonry？
当你的卡片高度差异极大（比如从 100px 到 800px）、需要滚动加载更多、或要求严格底部对齐时，CSS 的 column 布局会暴露它的本质限制：它不维护每列当前高度状态，也不提供插入点 API。
这时候 Masonry（Chrome 116+ 原生支持）或 css-grid + JS 补偿才是正解。但注意：原生 display: masonry 目前仅支持单轴（flow-direction: column），且不支持 gap 动态响应式缩放。
- 若需兼容 Chrome 115 及以下，仍得用
column回退 + JS Masonry 库（如 masonary.pkgd.min.js） - JS 方案必须监听图片加载完成（
img.onload）、字体加载（FontFaceSet.load）、以及 DOM 插入时机，否则初始布局又会错位 - 服务端渲染（SSR）页面中，JS 计算前的闪屏（FOUC）无法避免，得靠骨架屏或最小高度占位
实际项目里，column-count 是上线首选，但它不是“设了就完事”的属性——留白、断行、响应式切换这些细节，漏掉任何一个都会让瀑布流看起来像没调好的打印机。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
