onReachBottom不触发主因是滚动容器不可滚动，需确保内容高度超视口、避免固定高/空内容；小程序设onReachBottomDistance为150更稳，H5/App须用scroll-view的scrolltolower；数据追加应push而非合并数组，加载前校验状态，失败需提示。
onReachBottom 不触发？先看滚动容器是否“真可滚动”
很多情况下 onreachbottom 根本不执行，不是代码写错了，而是页面没产生有效滚动。uni-app 的 onreachbottom 依赖原生滚动容器（即整个页面内容高度 > 屏幕可视高度），一旦被 height: 100vh、position: fixed 或空内容撑不满一屏，就彻底失效。
- 根容器（如
<view class="container"></view>）不能设固定高或min-height: 100vh—— 这会截断滚动流 - 避免用
<view></view>包裹列表却不设display: block（某些平台下默认 inline） - 如果用了自定义导航栏或 tabbar，确保下方内容区域自然撑开，而不是靠
margin-top硬顶 - 小程序真机调试时，
console.log放在onReachBottom开头，滑到底没输出，基本就是滚动未激活
pages.json 里 onReachBottomDistance 怎么设才靠谱
onReachBottomDistance 不是越小越好，也不是写死 50 就万事大吉。它在不同端表现差异极大：微信小程序对距离感知偏“钝”，iOS 微信里设 50 常常要多拉 100px 才触发；H5 端则完全不走这个逻辑（得换 scroll-view）；App 端 nvue 页面压根不支持该生命周期。
- 小程序平台建议设为
150（实测触发更稳定） - H5 端必须弃用
onReachBottom，改用<scroll-view scroll-y></scroll-view>，并显式设置height - App 端若用 nvue，同样只能走
scroll-view的@scrolltolower，onReachBottom无效 - 不要在全局
pages.json里统一配，务必按页面单独配置，避免被覆盖
数据追加为什么卡顿？别直接 this.list = [...this.list, ...newData]
看似简洁的数组合并操作，在 uni-app + Vue 2/3 响应式系统里是性能杀手。尤其当 this.list 是几百项对象数组时，全量重建会触发大量依赖收集和视图 diff，滚动直接掉帧。
- 改用
this.list.push(...newData)—— 复用原数组引用，最小化响应式开销 - 上拉前必须校验
newData.length === 0，然后设this.noMore = true，否则用户会无限白屏等待 - 请求发起前加守卫：
if (this.loading || this.noMore) return，防止快速滑动触发多次 - 加载状态变更（如
this.loading = true）要放在请求前，且失败时也需恢复，否则按钮/提示永远卡在 loading
uni.stopPullDownRefresh() 能不能用在上拉里？
不能。这是个高频误用：uni.stopPullDownRefresh() 只用于结束下拉刷新动画，跟上拉毫无关系。有人在 onReachBottom 末尾也调它，纯属冗余——H5 下无效果，小程序/App 下虽无害但暴露了逻辑混淆。
- 上拉加载完成后，只需更新数据、重置 loading 状态、判断是否到底
- 真正要调的是
uni.hideNavigationBarLoading()？别用，这个 API 已废弃 - 网络失败时，至少调一次
uni.showToast({ icon: 'none', title: '加载失败' })，静默失败比卡住更伤体验 - 分页参数
this.pageNum++必须在请求成功后执行，否则失败重试会错页
最易被忽略的一点：所有上拉逻辑都建立在「滚动容器真实存在且持续可测量」前提下。一旦用了动态高度列表项、图片懒加载未设占位、或 scroll-view 高度靠 JS 计算但未做防抖/节流，scrolltolower 就可能漏触发或重复触发——这不是配置问题，是渲染管线失控。先稳住可视区域计算，再谈加载。
