uni-app实现瀑布流必须用JS动态维护列高，禁用flex等高方案；图片需预估宽高比占位，加载完成后再更新真实高度并重排；三端兼容需分别处理DOM获取方式与布局模式。
uni-app 用 flex 做等高瀑布流行不通
uni-app 的 view 默认不支持 css 多列（column-count），而真·瀑布流依赖的是「列内元素自然流式排列」，不是靠 flex 拉平高度。强行用 display: flex; flex-wrap: wrap + 等高子项，结果是所有卡片被拉成一样高，内容被截断或撑开留白——这不是瀑布流，是“砖墙流”。
真正可行的路只有一条：用 JS 控制每列高度，把 item 逐个塞进当前最短的列。
- 别碰
flex-direction: column+flex-wrap，H5 和小程序里行为不一致，iOS 下尤其容易错位 - uni-app 的
uni.createSelectorQuery()在列表滚动中频繁调用会卡顿，不适合实时计算高度 - 优先用「预设列数 + 客户端计算高度」方式，比如固定 2 列，JS 维护
leftHeight和rightHeight两个变量
uni-app 不等高瀑布流必须手写列队列逻辑
没有现成组件能跨端稳定工作。uni-app 官方没有 uni-waterfall，uView、uv-ui 的瀑布流组件底层仍是模拟列高，且在微信小程序中常因 getRect 异步时机问题导致首屏错位。
核心逻辑就三步：初始化列高数组 → 遍历 item → 找最小列高索引 → 插入并更新该列高度。
- 列高不能直接取
offsetHeight，需等图片加载完再算，否则高度为 0；可用@load事件触发单个 item 高度回填 - 初始渲染时先用骨架屏占位，避免闪动；真实高度拿到后再重排，否则 iOS 微信里会白屏一帧
- 不要在
onReachBottom里边请求边插入，要等整页数据返回后统一计算列分布，否则异步插入顺序错乱
// 示例：两列瀑布流核心分配逻辑
const columns = [0, 0]; // 当前列高
list.forEach(item => {
const minIndex = columns[0] <h3>uni-app 图片高度不确定时怎么处理列对齐</h3><p>瀑布流崩坏的主因不是逻辑错，而是图片没加载完就去量高度。uni-app 中 <code><image></image></code> 的 <code>height</code> 是未知的，CSS <code>aspect-ratio</code> 在旧版小程序基础库不支持，不能当真。</p>
- 服务端必须返回图片宽高比（如
aspect: "4:3"），前端用width * aspect算出预估高度，先占位再修正 - 用微信小程序的
image.onload或 H5 的img.naturalHeight获取真实高度，然后调用this.$forceUpdate()触发重排（仅 Vue2） - 避免用
v-for套image+ref查 DOM，小程序里 ref 可能为空；改用uni.createSelectorQuery().select(`#item-${id}`).boundingClientRect()并加 try/catch
uni-app 瀑布流在不同平台的兼容性雷区
H5、微信小程序、App（vue2/v3）三端渲染机制差异极大，同一套 JS 分配逻辑可能在某端完全失效。
- 微信小程序基础库 getComputedStyle，无法读取动态设置的
height，得靠boundingClientRect+ 回调 - App 端（尤其是 iOS）WebView 对
position: absolute的列容器支持差，建议用display: inline-block模拟列，配合vertical-align: top - uni-app 的
virtualList和瀑布流互斥——虚拟滚动需要线性结构，瀑布流是二维分布，二者不能混用；长列表只能分页 + 懒加载列数据
最麻烦的其实是图片加载完成时机和 DOM 可见性的错位：某个 item 还没出现在视口，但 JS 已经去查高度，结果查到 0。这种问题不会报错，只会让列越来越歪，直到用户滑到底才突然重排——这点最容易被忽略，也最难 debug。
