app端支付回调收不到是因为uni.onpaymentcomplete仅支持小程序，app需原生层主动通知js；ios用uni.postmessage，android用自定义广播或activity回传，且须配置原生插件与微信/支付宝相关参数。
uni-app App端支付回调为什么收不到
App端支付成功后，原生层不会自动触发JS层的回调函数，uni.onPaymentComplete 仅在微信小程序生效，App端压根不支持。这是最常被误以为“写错了逻辑”的根本原因——不是代码问题，是平台能力缺失。
实际必须靠原生层主动通知JS：iOS用uni.postMessage，Android用uni.getEnv配合自定义广播或Activity结果回传。但uni-app官方SDK默认不透出这些通道，得自己补。
- 检查是否在
manifest.json里勾选了「使用原生插件」，否则iOS侧uni.postMessage调用会静默失败 - Android端若用的是
uni.requestPayment调起支付宝/微信，务必确认build时勾选了对应原生支付插件（如Alipay、Wechat），否则success回调永远不进 - 不要依赖
uni.onThemeChange或uni.onShow监听支付返回——App切后台再切回前台时，页面生命周期可能已重置，状态丢失
如何让App支付成功后可靠跳转订单页
不能等“回调”，得把跳转逻辑前置到uni.requestPayment的success回调里——这个回调在App端是**支付调起成功即触发**，不代表用户付完了，但它是你唯一能稳稳拿到的时机。
后续靠服务端主动通知（Webhook）+ 客户端轮询兜底。前端跳转时，把订单号带上，页面内立刻查一次支付状态，避免白屏等待。
-
uni.requestPayment的success里立即uni.navigateTo({ url: '/pages/order/detail?order_id=' + orderId }) - 订单详情页
onLoad中立刻发起uni.request({ url: '/api/pay/status?order_id=' + orderId })查状态 - 服务端接口必须幂等，且响应含
status: 'success' | 'pending' | 'failed'，别只返回HTTP 200就完事 - 轮询间隔建议从1s开始，最多3次，之后降频到5s×3次，避免被服务端限流
Android微信支付回调收不到的典型配置漏项
Android下微信支付回调失败，90%是因为没配AndroidManifest.xml里的WXPayEntryActivity，或者包名/签名和微信开放平台注册的不一致。
uni-app打包时，这部分由原生插件生成，但如果你手动改过android/app/src/main/AndroidManifest.xml或升级过插件版本，很容易覆盖掉关键声明。
- 确认
AndroidManifest.xml中存在<activity android:name=".wxapi.WXPayEntryActivity">节点，且<code>exported="true" - 检查
build.gradle中applicationId是否和微信开放平台填的一致（注意：不是package，是applicationId） - 签名证书必须用正式打包用的keystore，调试时用debug.keystore会导致微信校验失败，报错
errCode:-1 - 微信开放平台的「应用签名」字段，要用
keytool -list -v -keystore xxx.jks -alias xxx取MD5，去冒号、转小写、不带空格
iOS支付完成后页面不刷新或状态不同步
iOS App支付完成会唤起微信/支付宝App，再通过Universal Links或URL Scheme跳回你的App。但uni-app的onShow不一定能捕获这次唤回，尤其当用户中途切换过其他App，系统可能丢掉启动参数。
更稳的方式是：在唤起支付前，把订单ID存进uni.setStorageSync('pending_order_id', orderId)，页面onShow时读它并查状态，查完立刻uni.removeStorageSync清理。
- 别用
uni.getStorage异步读取后再判断，要同步读，避免竞态 - 如果用户取消支付或支付超时，微信/支付宝仍会跳回App，所以
pending_order_id存在≠一定成功，必须查服务端 - iOS 14+限制后台运行，若支付耗时过长（比如用户去设置里开定位），App可能被系统挂起，此时
onShow不触发，只能靠服务端推送唤醒（需额外集成APNs）
支付状态这种强一致性要求的逻辑，永远以服务端为准。客户端所有“本地判断”都只是优化体验的临时手段，别让它承担业务正确性。
