瀑布流卡顿根源在于scroll高频触发、未节流的uni.createSelectorQuery()或setData、key失效导致整列重绘。应改用onReachBottom、唯一key、IntersectionObserver懒加载并及时销毁观察器。

uni-app 瀑布流分页加载卡顿的根源在哪

不是数据量大就一定卡，真正拖慢渲染的是 scroll 事件高频触发 + 每次都执行 uni.createSelectorQuery() 或反复 setData 大量节点。瀑布流组件（比如 uni-col + uni-row 拼的）一旦没做节流、懒加载或虚拟滚动，页面滑动时 CPU 占用飙升，iOS 尤其明显。

用 onReachBottom 替代 scrolltolower 防止误触

scrolltolower 在某些安卓机型（尤其 OPPO、vivo）上会因滚动惯性多次触发；而 onReachBottom 是 uni-app 生命周期钩子，由框架控制触发时机，更稳定可靠。

• 在 pages.json 中确保对应页面启用了下拉刷新和触底加载："onReachBottomDistance": 50
• 在页面 onReachBottom 方法里只做「是否允许加载」判断，不直接发请求：

  onReachBottom() {
    if (this.loading || this.hasMore === false) return;
    this.loading = true;
    this.loadMore();
  }

• 请求成功后重置 this.loading = false，并根据接口返回更新 this.hasMore

瀑布流列表必须用 key + track-by 控制重绘范围

uni-app 的 v-for 渲染瀑布流时，若不指定唯一标识，新增一页数据会导致整列重新 diff，UI 闪动、布局重排频繁。Vue 2（uni-app 当前主版本）不支持 key 在 template 标签上，所以必须落到每个子项节点：

uni-app

uni-app 是基于 Vue 的跨端开发框架，适合开发 H5、App、小程序、鸿蒙和多端业务应用。

下载

<view v-for="(item, i) in list" :key="item.id" class="waterfall-item"><image :src="item.imgUrl"></image><text>{{ item.title }}</text></view>

• item.id 必须是服务端返回的唯一字段，不能用数组索引 i —— 分页后索引会重复
• 如果后端没给 ID，至少用 item.id + page 拼接，避免 key 冲突
• 真机调试时打开「性能面板」观察 Layout 和 Paint 耗时，key 生效后这两项会明显下降

图片懒加载必须关掉 lazy-load 改用 IntersectionObserver

image 标签的 lazy-load 属性在 H5 和小程序表现不一致，且无法精确控制加载时机；uni-app 2.9+ 提供了 uni.createIntersectionObserver，这才是瀑布流图片加载的正确姿势：

• 每个图片容器（如 view.waterfall-img-wrapper）初始化一个观察器，监听其进入视口
• 观察回调中才设置 img.src，并立即销毁该 observer（避免重复触发）
• 务必加防抖：同一张图可能被多次进入/退出触发，用 if (this.loadedImgs.has(id)) return 去重
• 不要在 onLoad 后再调 setData 更新图片状态——直接改 img.src 即可，setData 只用于业务状态（如 loading 图标）

瀑布流真正的瓶颈不在「怎么加载」，而在「怎么不让它重绘」。key 写错、observer 不销毁、滚动事件没节流，这三处任何一个出问题，优化就归零。真机测的时候别光看「能不能加载」，得盯着 FPS 和内存曲线看。