瀑布流卡片飞出容器是因为未给容器设position: relative，导致absolute定位元素相对于视口而非容器定位；column-count+break-inside: avoid是唯一自动占位的纯css方案，grid需用minmax()实现弹性行高。
position: absolute 做瀑布流时，为什么卡片会飞出容器？
因为没设 position: relative —— 这是最常被忽略的前提。position: absolute 的元素默认相对于最近的已定位祖先（即 position 为 relative、absolute 或 fixed 的父级）定位；若找不到，就往上一直找到 ，最终相对于视口定位。
常见错误现象：top 和 left 看似写了，但所有卡片全堆在页面左上角，或随滚动“飘走”。
- 必须给瀑布流容器加
position: relative - 不能只靠 CSS 硬写
top: 200px—— 卡片高度动态变化（如图片加载后撑开），后续所有top值立刻失效 - JS 计算时，要读取前一张卡片的
offsetTop + offsetHeight，再加间距，才是可靠依据
column-count + break-inside: avoid 是唯一能自动占位的纯 CSS 方案
它不靠定位，而是浏览器原生的内容流分栏机制：把容器当“报纸栏”，按列高自动切分内容块，并保证单个卡片不跨列断裂 —— 这就是你想要的“占位效果”：卡片在哪一列、占多高，由内容实际高度和列宽共同决定，无需手动干预。
关键配置只有三行，且兼容性极好（Chrome 10+、Firefox 52+、Safari 14.1+）：
.waterfall {
column-count: 3;
column-gap: 16px;
}
.waterfall > * {
break-inside: avoid;
margin-bottom: 16px;
}
-
break-inside: avoid必须加在子项上，否则卡片可能被硬生生切成两半跨列显示 - 不要给子项设
width: 100%—— 它会强制填满当前列宽，破坏自然流式行为 - 响应式调整列数时，优先用
column-width而非column-count，例如column-width: 240px，浏览器自动计算能放几列
Grid 布局里，grid-auto-rows: minmax(100px, auto) 才真能“占位”
很多人误以为 grid-auto-rows: 100px 就能固定每行高度、实现占位，结果是图片被裁剪或留白失控。真正起作用的是 minmax(100px, auto)：它让每行至少 100px 高，但允许根据内容（比如一张高图）自动撑开 —— 这样 Grid 才能按需分配空间，避免错位。
典型错误配置：grid-auto-rows: 1fr 或 grid-auto-rows: 200px，会导致所有行等高，失去瀑布流意义。
- 搭配
grid-template-columns: repeat(auto-fill, minmax(240px, 1fr)))，列数随容器宽度自适应 - 务必给图片加
width: 100%; display: block;，否则 inline 元素默认基线对齐会在底部留 4px 空隙，导致整列“虚高” - 用
gap控制间距，别用margin—— margin 在 Grid 中可能被忽略或引发塌陷
为什么 grid-auto-flow: dense 不能替代瀑布流占位？
它只是“填空”，不是“按列平衡”。grid-auto-flow: dense 的作用是：当某张卡片因高度大而跳过某格时，后续小卡片会回填前面的空位 —— 但它完全不管列高是否均衡，也不改变卡片在列中的垂直顺序。视觉上仍是顶部对齐、底部参差，无法模拟 Pinterest 那种“各列底部尽量齐平”的占位感。
更麻烦的是：一旦卡片内有懒加载图片，高度突变后，下方卡片不会自动重排，只会突然下坠，造成布局抖动。
- 适合场景：卡片高度差异小、内容静态、且只需紧凑排列（如仪表盘小部件）
- 不适合场景：图集、博客列表、商品卡片等高度剧烈波动的内容流
- 它和
column-count不是互斥方案，而是根本不同模型 —— Grid 是网格坐标系，Column 是文档流分栏
真实项目中，column-count 方案最稳，但受限于不能精确控制单个卡片位置；position: absolute 最灵活，但 JS 维护成本高；Grid 折中，但对图片样式细节极其敏感 —— 选哪个，取决于你愿不愿意为“占位”多写一行 display: block，或者多跑一次 DOM 高度计算。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
