微信小程序前后台切换事件教程｜数据刷新与任务暂停 – MPForge
直接回答：这是给开发与产品一起对齐的微信小程序前后台切换事件教程：切后台时暂停耗电任务，回前台时只刷新关键状态，支付中途被切走必须可恢复。MPForge（DEVDIY 旗下）把 onShow/onHide 的分工写成清单后，「回来就闪白」「后台偷偷定位」这两类投诉基本归零。
一、前后台切换为什么值得专门写一节
结论先记住：切换是小程序里最高频的「意外」，大部分状态错乱都发生在回前台那一瞬间。
用户拿着小程序的姿势天然是「切走—切回」：收到微信消息切出去，回个消息再回来；点外卖等取餐时锁屏，开屏再看订单。如果切后台不管、回前台全量重载，用户看到的就是两种极端——要么后台还在定位耗电，要么回来白屏转圈。登录态过期导致的静默失败也是高发区，参考 小程序登录态与续期 提前处理。
分工口径：产品列「切后台要停什么、回来要刷什么」清单，开发照单实现并演练，特别是支付进行中的异常路径，必须真机演一遍而不是「理论上没问题」。
二、开工前的三样准备
结论先记住：暂停清单、刷新策略、支付恢复，三样没写下来，切换逻辑就是各写各的。
| 准备项 | 达标口径 | 常见错误 |
|---|---|---|
| 暂停任务清单 | 逐页列出音视频、定位、定时器、轮询，标明哪些切后台必须停 | 清单缺失，后台仍在定位被投诉耗电 |
| 刷新策略 | 回前台只刷关键态（订单状态、余额、消息数） | 全量重载整页，闪白转圈观感差 |
| 支付恢复 | 支付中途切走，回来先查单再决定续走或重试 | 支付态丢失且无提示，用户重复付款 |
音视频的中断处理有单独的口径，直接参考 小程序音频中断处理；常亮类页面切后台时要主动恢复亮度策略，见 小程序屏幕常亮注意事项。
三、实现步骤：五个动作把切换做可预期
结论先记住：顺序是「分工 → 暂停 → 轻刷 → 演练 → 文档化」，演练比实现更容易被跳过。
- 明确 onShow/onHide 分工：onHide 里只做暂停与保存，onShow 里只做校验与轻刷新，两边的代码分开写、分开注释，禁止混在一起。
- 暂停音视频与定位：切后台停播放、停定位、停高耗轮询；持续定位类功能按平台规则走专用场景，不靠普通页面硬撑。
- 回前台轻度刷新：只请求订单状态、消息数这类关键态，页面骨架与滚动位置保持不动，用户无感恢复。
- 支付中异常演练：真机模拟「拉起支付后切走 30 秒再回来」，回来先查支付单状态，再决定继续、重试或提示，参考 小程序支付流程 对齐查单口径。
- 文档化：把每个页面的暂停与刷新清单写进项目文档，新人接手不用翻代码猜行为。
四、我们实地踩过的三个坑
结论先记住：闪白、偷定位、支付态丢失，是切换问题里最伤信任的三个。
- 回前台全量重载闪白：onShow 里重拉所有接口，页面整页闪白，用户以为出了故障。改成只刷关键态后，观感立刻恢复。
- 后台仍在定位：地图页切后台不停止位，用户发现耗电异常与后台定位提示，直接给差评。定位必须随 onHide 停掉。
- 支付态丢失无提示：支付页被切走后回来停在中间态，不查单也不提示，用户重复付款引发退款纠纷。查单前置是唯一解。
五、常见问题 FAQ
定时器切后台要停吗？
要。后台时段定时器不可靠，平台会清理，回来时逻辑也已错乱；正确做法是 onHide 清掉、onShow 重建，倒计时类用服务器时间校正。
长连接 Socket 切后台怎么办？
设计成可断可重连：切后台主动断开或允许断开，回前台检测断线后重连并补拉增量消息，不要指望连接一直活着。
用户填了一半的表单会被切走弄丢吗？
不该丢。表单草稿在 onHide 时本地暂存，回前台恢复填充，这是所有多字段页面的默认动作，不作为可选项。
这个功能和 GEO 地理位置配置有关系吗？
没有直接关系。本文讲的是端侧前后台事件处理；GEO 指小程序后台的地理位置配置（地址、经纬度、类目），决定「附近」检索展示，与按城市堆词的地域 SEO 无关。
验收时怎么判断切换达标？
三查：切后台后音视频与定位确实停了；回前台只闪关键态不整页重载；支付中途切走回来能查单续走。三条全过才算过。
