uni-app 中不存在微信支付默认回调弹窗，所有弹窗均由开发者手动调用 uni.showToast 等 API 实现；常见问题包括重复提示、状态误判及插件自带 UI，需检查回调逻辑、轮询机制与插件配置。
uni-app 里根本不存在“微信支付默认回调弹窗”
这是最常被误解的前提：微信支付本身不向前端弹任何回调提示，uni.requestPayment 调起的是微信原生支付界面（输密码/指纹页），支付完成后微信直接关闭该界面并把控制权交还 App 或小程序——它不会主动弹出 success/fail 提示框。
你看到的“弹窗”，几乎全是开发者自己写的：uni.showToast、uni.showModal 或页面内 v-if 控制的状态提示。只要没在 success 或 fail 回调里手动调用这些 API，就不会有弹窗。
常见错误现象：
- 支付成功后连续弹两个 toast：因为你在
success里调了一次uni.showToast，又在后续轮询接口返回成功时又调了一次 - App 端支付完闪现“支付成功”又消失：因为
onShow中读取缓存跳转时，误把未清理的旧状态当新结果用了
为什么小程序里有时会“自动弹窗”
部分团队封装了统一支付工具函数，内部默认加了 uni.showToast({ title: '支付成功' })；或者用了第三方 UI 库（如 uView、uCharts）的支付组件，其内部实现了反馈逻辑。
排查方法：
- 全局搜索
uni.showToast、uni.showModal、uni.showLoading，看是否出现在uni.requestPayment的success/fail回调中 - 检查是否引入了类似
@dcloudio/uni-ui或业务封装的PayButton组件，点进去看源码 - 确认
manifest.json中「微信小程序」配置下是否启用了「调试模式」，某些低版本基础库会在开发环境下打印模拟回调日志（非弹窗，但容易误判）
App 端所谓“回调弹窗”其实是 native 插件行为
Android/iOS 原生插件（如 Wechat、Alipay）在支付完成返回时，若未正确配置或插件存在 Bug，可能触发 uni.showToast 的 fallback 提示——但这属于插件实现缺陷，不是微信或 uni-app 标准行为。
典型表现：
- iOS 上支付成功后弹出“支付已完成”，但 JS 层
success回调尚未执行 - Android 使用旧版
uni-pay插件时，插件内部硬编码了 toast 提示
解决方式：
- 升级到最新版
@dcloudio/uni-plugin-wechat（2026 年 7 月后发布），该插件已移除所有默认 UI 行为 - 若自行维护原生插件，检查 iOS 的
WXApiDelegate实现和 Android 的WXPayEntryActivity中是否调用了uni.showToast - 禁用插件自带 UI：在插件配置中设
showToast: false（如有此选项）
真正要关掉的，是你的轮询成功后的二次提示
很多项目在 success 回调里只做跳转，然后在订单页 onLoad 中轮询 /api/pay/status?order_id=xxx，等接口返回 status: 'success' 后再弹一次成功 toast——这才是用户感知到的“第二次弹窗”。
建议做法：
-
uni.requestPayment的success回调里不做任何 UI 提示，只跳转并传参：uni.navigateTo({ url: '/pages/order/detail?order_id=' + orderId + '&from=pay' }) - 订单页
onLoad中，若from === 'pay'，则立即查状态；但仅在首次轮询返回status === 'success'时调用uni.showToast，且加防抖（例如 500ms 内重复响应忽略） - 服务端 notify_url 必须保证幂等，避免因重试导致前端多次收到“已支付”通知
最易忽略的一点：App 端轮询必须带请求头 Authorization 或有效 session，否则可能因鉴权失败反复返回 pending，进而反复触发 toast。
