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