瀑布流容器高度塌陷的根本原因是浏览器无法预知异步插入的DOM，解决方案是预先设置min-height并配合骨架屏占位，插入后强制重排，用IntersectionObserver监听底部哨兵元素实现可靠懒加载。
异步加载数据时，瀑布流容器高度塌陷是常态——不是你代码写错了，而是浏览器根本“看不见”还没插入的 DOM。关键不是等数据回来再撑高，而是让容器从一开始就有可预测的高度上下文。
为什么容器高度会突然塌掉
常见错误是把 container 设成 position: relative 或 height: auto，然后靠 JS 动态 append 子项。但 JS 插入前，容器高度为 0；插入后若没触发重排或没设最小高度，父级就按 0 高度渲染，导致下方内容上跳、滚动错乱。
-
height: auto在空容器里就是 0，不是“待定”，而是确定值 - 用
display: grid或column-count的容器，若子项为空或未渲染完成，浏览器不会预留空间 - 图片异步加载 + JS 动态插入，双重延迟叠加，容器高度在几轮渲染中反复归零
给 container 设 min-height + 占位骨架
最轻量且兼容性最好的做法：不等数据，先占位。用 min-height 锁住底线，再用骨架（skeleton）模拟首屏预期高度。
-
min-height值建议按首屏列数 × 单列预估平均高度（如 3 列 × 300px = 900px），别写死 px，可用min-height: 80vh或min-height: 700px - 骨架不用复杂动画，一个带
aspect-ratio的<div class="skeleton">就够，宽高比匹配图片原始比例 - 避免对
container设overflow: hidden，否则骨架或后续插入的 item 可能被截断
JS 插入后主动触发容器重排
单纯 appendChild 不保证容器立刻重绘高度，尤其在 fast-refresh 或 SSR hydration 场景下。需要轻微干预布局计算。
立即学习“前端免费学习笔记（深入）”；
- 插入完一批 item 后，读一次
container.offsetHeight（哪怕不存变量），强制触发回流 - 如果用
Masonry库，调用masonry.layout()，别依赖自动检测——它默认只监听 resize，不监听 DOM 变更 - 避免在滚动事件里高频调用 layout，加节流（throttle）或用
requestIdleCallback延后执行
用 IntersectionObserver 替代 scroll 事件做懒加载
滚动到底部才加载下一页，听起来合理，但容易造成容器高度“断层”：新数据插入时，旧容器还没来得及扩展，用户已滚过目标区，触发多次加载或漏加载。
- 用
IntersectionObserver监听容器底部的 sentinel 元素，比监听window.scrollY + window.innerHeight >= container.scrollHeight更可靠 - sentinel 元素必须是
container的最后一个子元素，且设margin-top: 1px防止因四舍五入被忽略 - 加载新数据前，先给
container插入一个占位<div class="loading-placeholder" style="height: 200px"></div>，撑开高度再替换
真正难的不是算高度，而是让所有环节——CSS、JS、图片加载、滚动监听——都共享同一套高度预期。一旦某个环节脱离这个预期（比如图片 onload 比 layout 晚，或 skeleton 宽高比和真实图不一致），容器就会抖动或塌陷。
