移动端瀑布流最优解是flex双列+高度预估+异步修正：用宽高比预估初始高度，图片加载后通过style.height和requestanimationframe微调，左右列独立维护高度并动态分配新项。
移动端瀑布流布局的性能最优解，不是选“最炫”的方案，而是选“最不拖慢滚动、最少重排、最易控制高度顺序”的方案。纯 CSS Multi-column 在渲染速度上确实快，但它无法解决内容按时间顺序从左到右排列的核心体验问题；CSS Grid 的 grid-auto-flow: dense 看似能模拟瀑布流，但在移动端 Safari 和微信小程序 WebView 中支持不稳定，且列高无法主动干预，容易导致顶部留白或错位。
Multi-column 方案为何在真实业务中“看起来快，用起来难受”
它依赖浏览器原生的列填充逻辑：内容按 DOM 顺序逐个填满第一列，再填第二列……这意味着你传入的数据是按发布时间倒序（最新在前），但渲染结果却是“左边全是老内容，右边全是新内容”。用户直觉是“从左往右读”，而实际阅读路径被强制打断。
更关键的是，break-inside: avoid 并不能 100% 防止截断——当卡片内含异步加载的图片或文字行数动态变化时，仍可能触发重排。一旦发生，整个列容器会重新计算高度，触发 layout thrashing。
- 必须配合
column-fill: auto，否则多列高度差异极大 - 无法监听单个 item 渲染完成后的实际高度，所以无法做懒加载占位或骨架屏对齐
- 微信小程序中
column-count在 iOS 下偶发失效，需加transform: translateZ(0)强制硬件加速才能稳定
Grid 布局在移动端瀑布流中的真实兼容性陷阱
CSS Grid Level 2 的 grid-template-rows: masonry（原生瀑布流支持）目前仅 Chrome 117+ 和 Safari 17.4+ 支持，iOS 微信内置 WebView 基于旧版 WKWebView，基本不可用。而退而求其次用 grid-auto-flow: dense + 手动设置 grid-row-end，则需要 JS 提前知道每个 item 高度——这又回到了“图片未加载，高度未知”的老问题。
更隐蔽的问题是：Grid 容器一旦设置了 grid-template-rows（哪怕写 auto），就不再自动响应子项内容高度变化；若靠 JS 动态更新 style.gridTemplateRows，每次更新都会触发全量重排，滚动中 setData 多次直接卡死。
- Android 微信 v8.0.44 之前，
grid-auto-flow: dense对position: relative子项的支持有 bug，元素会错位 - 所有 Grid 瀑布流方案都无法在 item 插入后平滑过渡高度（无 CSS transition 支持），视觉上就是“啪”一下弹下来
- 如果你用
grid-column: span 2让某个大图横跨双列，dense 模式下后续小卡片可能被挤到很下方，破坏“最小列高优先”逻辑
真正兼顾性能与体验的落地选择：Flex 双列 + 高度预估 + 异步修正
这不是“折中”，而是当前移动端生态下唯一能同时满足三项硬指标的方案：滚动不卡顿、数据按时间顺序从左到右呈现、图片加载后不抖动。核心在于把“高度计算”从渲染后（被动）移到渲染前（主动预估）+ 渲染后（异步微调）两个阶段。
- 初始渲染用固定宽高比预估高度：
height = width * (expectedAspectRatio)，比如商品图统一按 4:3，文字卡片按行数 × 行高估算 - 图片加载完成时，用
bindload拿到真实尺寸，只更新该 item 的style.height（非 setData），避免整列重绘 - 左右两列用两个独立数组管理，JS 维护
leftHeight和rightHeight累计值，新 item 总是推给较短列 - 为防极端情况（如某列突然插入一个超长图文卡片），加入最大高度阈值，超过时强制切到另一列，避免单列无限拉长
真正的难点不在“怎么写”，而在“什么时候更新高度才不触发 layout shift”。很多团队卡在图片加载完成那一刻的 setData 调用上——只要把高度信息塞进 data 再 setData，整个列表就会重绘。必须用原生 style 更新 + requestAnimationFrame 节流，才能让修正过程肉眼不可察。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
