css grid 无法实现真正瀑布流，因其列高由最高项决定，不能动态错位；需用 js 维护列高数组并结合 getboundingclientrect() 精确布局，配合 contain、aspect-ratio 等优化防卡顿。
Grid 实现瀑布流时为什么 item 高度塌陷
用 display: grid + grid-template-columns: repeat(auto-fill, minmax(300px, 1fr)) 看似能“模拟”瀑布流，但实际所有 item 会按行平铺，不是真正瀑布效果——因为 Grid 的列高由该列最高项决定，不会让后续 item “掉进”前面列的空隙里。
真正瀑布流要求每个 item 独立定位、垂直堆叠不打断，而纯 CSS Grid（不含 grid-auto-flow: dense 配合 grid-row 手动控制）做不到动态高度错位。别被“CSS 新特性很强大”带偏，这里它天生不适用。
- 如果你只是想响应式多列等高布局，Grid 完全够用；但要实现 Pinterest 那种参差错落，Grid 不是正解
-
grid-auto-flow: dense只能重排已知高度的 item，无法应对图片加载后高度变化、字体渲染差异等 runtime 动态场景 - 服务端预计算高度再下发
grid-row值？可行但维护成本高，且首屏仍可能闪动
JS 动态计算偏移量的核心逻辑是什么
本质是维护一个列高数组，每次插入新 item 时，找到当前最短列，把 item 的 top 设为该列当前高度，再更新该列高度 += item.offsetHeight。
关键不在“怎么算”，而在“什么时候算”和“怎么防抖”。常见错误是监听 load 后立刻计算，结果图片还没解码完成，offsetHeight 拿到 0 或不准确值。
立即学习“前端免费学习笔记（深入）”；
- 对图片使用
img.addEventListener('load', handler)，但必须确保 img 已挂载且 src 已设置；否则事件不触发 - 更稳妥做法：用
IntersectionObserver+ 回调中检查el.offsetHeight > 0，或降级到setTimeout微任务轮询（最多 3 轮，避免死循环） - 列高数组建议用
Float32Array初始化，避免频繁 push / sort，性能敏感场景下比普通数组快 20%+
const cols = new Float32Array(3).fill(0);
function appendItem(el) {
const minHeight = Math.min(...cols);
const idx = cols.indexOf(minHeight);
el.style.cssText = `position: absolute; top: ${minHeight}px; left: ${idx * 320}px;`;
cols[idx] += el.offsetHeight;
}为什么 getBoundingClientRect() 比 offsetTop + offsetParent 更可靠
offsetTop 依赖最近的 position: relative/absolute 祖先，一旦中间有 transform、filter 或 containing block 变更，值就失效；而 getBoundingClientRect() 始终基于视口，不受祖先样式干扰，是唯一能拿到真实渲染位置的方法。
但要注意：它返回的是浮点数，直接用于 top 设置会导致 subpixel 渲染模糊；同时在滚动中频繁调用会触发同步布局（layout thrashing）。
- 只在 item 插入后、且确认已 layout（如
offsetHeight有值）再调一次getBoundingClientRect()，缓存结果，别每帧都查 - 设置
top时用Math.round(y)，避免小数像素 - 如果容器有
transform: scale(0.9)，getBoundingClientRect()返回值已自动缩放，无需额外除算
移动端滚动卡顿的三个隐蔽原因
瀑布流在 iOS Safari 或低端 Android 上容易掉帧，往往不是 JS 计算慢，而是渲染层被意外阻塞。
- 给每个 item 加
will-change: transform？错。这会让 GPU 过早提升图层，内存暴涨反而拖慢；仅对正在动画的 item 动态添加 - 用
top/left定位却没设contain: layout paint，导致每次插入都触发全页面重排；加在容器上可限制影响范围 - 图片未设
width/height属性，加载时重排 + 重绘双触发；服务端务必传宽高，前端 fallback 用 aspect-ratio
复杂点在于：这些优化必须组合生效才明显。单开 contain 可能无效，单加 aspect-ratio 解决不了重排，只有三者齐备，才能让 200+ item 的列表滚动保持 60fps。
