uni.setInterval在后台会暂停，不可用于自动结束任务；应以服务端下发的expireAt时间戳为基准，通过Date.now()实时比对判断是否超时，并配合状态锁防重复执行。
uni.setInterval 在后台会暂停，不能直接依赖它做“自动结束”
uni-app 的 uni.setInterval（以及原生 setInterval）在小程序或 App 进入后台时会被系统强制暂停——这是平台限制，不是 bug。这意味着：你设了个 60 秒倒计时，用户切到微信聊天界面再回来，可能还剩 59 秒，但实际已过去 3 分钟。所谓“自动结束任务”，如果靠它驱动，大概率失效。
- 小程序端（微信/支付宝/字节）：页面 onHide 后定时器完全冻结
- App 端（iOS/Android）：iOS 后台最多运行 30 秒，Android 行为不一，但基本不可靠
- Web 端虽不停，但 uni-app 多端项目必须按最弱平台设计
所以，“倒计时自动结束任务”的本质不是“每秒减一”，而是“判断当前是否已超时”。关键在时间锚点，不在循环节奏。
用 Date.now() + 服务端时间戳做基准判断
真正可靠的方案是：记录一个“截止时间点”，每次需要检查时，用 Date.now() 和它比大小。这个截止时间必须来自服务端（避免客户端时间被篡改或错乱），单位统一为毫秒。
- 不要用
countdown: 60这类剩余秒数变量存状态——它无法跨生命周期存活，且易被重置 - 推荐结构：
expireAt: 1743165680000（服务端下发的毫秒时间戳） - 检查逻辑写成：
Date.now() >= this.expireAt，返回布尔值即可触发结束动作 - 可在
onShow、onResume、按钮点击、接口回调等任意时机执行该判断
例如验证码场景：用户获取后，后端返回 { expire_at: 1743165680 }（秒级），前端立刻转为 expireAt = expire_at * 1000 存 data 或 vuex。
需要 UI 倒计时展示？用 requestAnimationFrame + 时间差计算
如果既要视觉上“动起来”的倒计时（比如显示“02:18”），又要后台唤醒后仍准确，就不能靠 setInterval 每秒更新，而得用 requestAnimationFrame 驱动，并每次都重新算剩余毫秒。
- 每次帧回调中执行：
const remainMs = Math.max(0, this.expireAt - Date.now()) - 再格式化为分秒：
Math.floor(remainMs / 1000 / 60)、Math.floor((remainMs / 1000) % 60) - 比 setInterval 更准，且在页面激活瞬间就能刷新到真实剩余时间
- 注意：需在
onHide时cancelAnimationFrame，onShow时重启，避免内存泄漏
别碰 uView 的 <uni-countdown> 组件做“业务终止逻辑”——它底层仍是 setInterval，只适合静态促销展示，不适合强时效任务。
自动结束任务 ≠ 自动调接口，要加防重和状态锁
“自动结束”常被理解为“时间一到就发登出请求”或“取消订单”。但网络延迟、重复触发、多端登录等情况会让这事变复杂。
- 必须加状态标记，如
isTaskEnded: false，首次触发结束逻辑后立即置为true - 结束动作（如调
uni.removeStorageSync('token')或发登出 API）前，先判断if (!this.isTaskEnded && Date.now() >= this.expireAt) - API 调用失败不能重试无限次，建议配合本地存储记录
endedAt时间戳，下次进入直接跳过 - 若任务涉及服务端状态（如订单锁定），前端仅做提示+禁用操作，最终以服务端定时任务或幂等接口为准
最常被忽略的是：用户反复切前后台，onShow 可能高频触发，没锁的状态下，登出逻辑可能跑 5 次——token 被删了，但登出接口却因 401 失败了 4 次，日志里全是噪音。
