微信小程序不支持真正的后台周期性更新，进入后台后5秒内被冻结，JS线程与定时器全部停止；仅能通过onShow+缓存策略实现伪后台更新，或依赖服务端推送（如订阅消息、WebSocket）保障实时性。
微信小程序不支持真正的“后台周期性更新”——这是硬性限制，不是代码写得不够好。
微信小程序根本没有后台持续运行能力
小程序在进入后台后，最多 5 秒内会被系统冻结，之后所有 JS 线程、定时器、setInterval、setTimeout 全部停止。所谓“后台更新”，实际只能靠微信主动唤起的有限几种场景触发：
- 用户点击订阅消息（需用户主动授权且点击）
- 收到服务端推送的模板消息（仅限已提交审核通过的模板，且用户必须点击才触发）
- 用户通过分享卡片、扫码、搜索等重新进入小程序（非后台唤醒）
-
onBackgroundAudioPause/onBackgroundAudioPlay等音频相关生命周期（仅限正在播放背景音频时有短暂后台执行权）
没有 uni.startLocationUpdateBackground 这类 API；wx.startBackgroundFetch 也已于 2022 年被微信官方废弃，目前所有基础库版本均不可用。
能做的只有“伪后台更新”：用 onShow + 缓存策略兜底
用户切出再切回（即触发 onShow）是唯一稳定可捕获的时机。此时应检查数据新鲜度，而非盲目重拉。
- 给关键数据加时间戳缓存：例如
uni.setStorageSync('order_status_123', { status: 'paid', timestamp: Date.now() }) - 在
onShow中判断是否超时（如 > 30s），再决定是否调接口刷新：if (Date.now() - cached.timestamp > 30 * 1000) { fetchOrder() } - 避免在
onShow里无条件调用uni.showToast或弹窗，会打断用户操作流 - 对列表页，可只校验顶部几条数据的状态，而非整页 reload
想让数据“看起来实时”，得靠服务端推+前端状态同步
真要实现订单状态变更、聊天消息到达这类体验，不能依赖前端轮询或后台任务，必须走服务端主动通道：
- 用户下单/支付成功后，服务端立即向微信订阅消息模板池投递一条“订单状态更新”通知（需用户提前订阅）
- 小程序监听
wx.onMessage（仅限小游戏或部分特殊类目，普通小程序不支持）——这条路基本走不通 - 更现实的做法：在用户打开小程序时，用 WebSocket 或长轮询（
uni.connectSocket）建立轻量连接，接收服务端广播的状态变更事件 - 若用 uniCloud，可在云函数中监听数据库变更（如
db.collection('orders').watch()），再通过uniCloud.callFunction推送变化到前台
真正容易被忽略的是：开发者常把“iOS App 后台定位”或“Android 前台服务”的逻辑直接套到小程序上，结果卡在权限申请、API 报错 undefined is not a function 或静默失败。微信小程序的后台模型和原生 App 完全是两套体系，强行模拟只会浪费调试时间。
