onReachBottom不触发需检查：pages.json中enablePullDownRefresh为false且onReachBottomDistance合理；禁用scroll-view改用bindscrolltolower；根节点避免height:100vh或position:fixed；真机注意网络白名单与WebView兼容性。
uni-app 里 onReachBottom 不触发？检查这几个地方
上拉加载更多在 uni-app 里本质靠 onReachBottom 生命周期钩子响应，但它不是“只要写了就自动生效”。常见现象是滚动到底部毫无反应——大概率是页面没启用触底检测或被其他逻辑拦截。
-
onReachBottom只在pages.json中对应页面的"enablePullDownRefresh": false（或未设）且"onReachBottomDistance"配置合理时才工作；默认距离是 50px，如果列表内容太短、或者有吸顶/固定头遮挡可视区域，可能永远达不到触发条件 - 使用了
scroll-view自定义滚动容器时，onReachBottom完全失效——它只监听页面级滚动，此时必须改用scroll-view的bindscrolltolower事件 - 页面根节点被设置了
height: 100vh或position: fixed，导致 body 实际可滚动高度为 0，onReachBottom失去判断依据
分页请求怎么写才不重复、不漏数据
后端分页通常用 page + pageSize 或 offset + limit，但前端容易在翻页逻辑里埋下竞态或状态错乱的坑。
- 请求发起前加个开关：用
isFetching控制，避免快速上拉多次触发；请求开始设为true，成功/失败后都设回false - 不要直接在
data里拼接新数据：用this.list = [...this.list, ...res.data]是安全的，但若后端返回的是“当前页全部数据”而非“追加数据”，需确认是否要清空再赋值 - 后端返回
total或hasMore字段时，优先用它判断是否还有下一页；别只靠当前页码硬算，比如page * pageSize >= total—— 后端总数可能动态变化
下拉刷新和上拉加载能共存吗？怎么配
可以共存，但配置稍有讲究。uni-app 允许同时开启下拉刷新和触底加载，但两者触发机制不同，容易互相干扰。
- 必须在
pages.json对应页面配置："enablePullDownRefresh": true和"onReachBottomDistance": 50（数值可调，但不能为 0） - 下拉刷新会重置滚动位置，触发
onPullDownRefresh；此时若用户立刻上拉，onReachBottom仍会按新位置计算，不会误触发——前提是没手动调uni.pageScrollTo干扰滚动锚点 - 刷新完成后记得调
uni.stopPullDownRefresh()，否则下拉动画卡住，后续onReachBottom也可能失灵（实测某些 Android 端 WebView 有此问题）
真机调试时加载失败，但模拟器正常？查网络和平台差异
最典型的是 iOS 微信内置浏览器或安卓某厂商 WebView 对 Promise / fetch / 跨域策略更严格，而 H5 模拟器跑得太“理想”。
- 检查请求是否用了
uni.request：它比原生fetch兼容性更好，尤其对 HTTPS 证书、HTTP 重定向、超时控制更稳；避免混用axios或原生fetch导致部分平台报Network Error - 安卓低端机或微信内嵌页可能出现 scroll 事件延迟，导致
onReachBottom触发滞后甚至丢失；可在onReachBottom内加个防抖：比如if (this.isFetching) return;+setTimeout(() => { this.loadMore() }, 100) - 真机日志里看到
request:fail net::ERR_CONNECTION_TIMED_OUT，大概率是域名没在manifest.json的 “网络域名” 白名单里，H5 模式下尤其要注意
实际分页最难的不是写逻辑，而是让“触底”这件事在各种机型、各种嵌套结构、各种网络条件下稳定发生。很多问题表面是代码没写对，其实是滚动上下文被隐藏容器、CSS 布局或平台 WebView 行为悄悄改写了。
