uni-app模拟器中toast/loading不自动消失是因模拟器忽略duration定时逻辑，需手动调用hideAPI；真机正常。应封装请求层统一控制显隐，避免跨页面、并发、custom tabbar或nvue导致的遮挡/失效问题。
uni-app 小程序模拟器里 uni.showToast / uni.showLoading 提示框不自动消失？
这不是 bug，是模拟器行为和真机不一致导致的——模拟器不会自动触发 hideToast 或 hideLoading 的默认生命周期，必须显式调用关闭 API。
常见现象：调用 uni.showToast({ title: '提交成功' }) 后，提示框一直卡在屏幕中央；uni.showLoading 之后没手动 uni.hideLoading()，加载框就永远转着。
- 真机上
duration到期后会自动隐藏（如uni.showToast默认 1500ms） - 模拟器（尤其是 HBuilderX 内置的微信/支付宝模拟器）往往忽略这个定时逻辑，只靠你手动关
- 并发请求中若多个
showLoading没配对hideLoading，会导致后续所有hideLoading失效（因为没有 loading 状态可关）
为什么 uni.hideToast() 有时没反应？
因为 uni.hideToast() 只能关闭最近一次 uni.showToast 打开的提示框，且不能跨页面、跨组件作用——它不是全局队列管理，而是“单次覆盖”行为。
- 如果在 A 页面调用
showToast，跳转到 B 页面再调用hideToast，大概率无效（B 页面无活跃 toast 实例） - 如果 A 页面连续调用了两次
showToast，第一次的提示框会被第二次覆盖，此时调用一次hideToast只能关掉第二个，第一个早已不可见但未被清理（无实际影响） - 不要依赖
setTimeout+hideToast做兜底——模拟器里定时器可能不准，或页面销毁后回调仍执行，引发报错
如何安全地统一管理提示框开关？
核心思路：把提示状态收口到请求层，避免业务代码到处写 show/hide，尤其别在 finally 里调用 hideLoading ——那是 Promise 层逻辑，和 uni API 生命周期无关。
- 封装请求函数时，用参数控制是否显示 loading：
request({ url: '/api/user', loading: true, loadingText: '获取中...' }) - 在 request 内部判断：
if (params.loading) uni.showLoading({ title: params.loadingText || '加载中' }) - 在
complete回调里关：uni.request({ ..., complete() { if (params.loading) uni.hideLoading() } }) - 禁止使用全局变量（如
isLoading = true）标记状态——并发请求下会被覆盖，导致漏关或误关
小程序真机调试时提示框异常，模拟器却正常？
这种情况多发生在「自定义 tabbar」或「nvue 页面」中：原生组件层级高于 webview，uni.showToast 这类 API 渲染在 webview 层，容易被遮挡或丢失焦点。
- 微信小程序真机上，如果页面启用了 custom tabbar，
showToast可能被 tabbar 容器截断或渲染偏移 - nvue 页面不支持
uni.showToast，必须改用uni.showModal或自定义 view 动画实现 - 模拟器因渲染机制简化，反而表现“正常”，掩盖了真机兼容问题
- 验证方式：在 pages.json 中临时关闭 custom tabbar，或换用普通 vue 页面复现
