小程序回滚：别让一次发布毁掉整晚

上周三晚上十一点，我正准备关电脑，群里蹦出一条消息：线上小程序的订单页白屏了。那一刻的心情，做过独立开发的人都懂——不是怕修 bug，是怕修 bug 的时候用户还在不停地下单。

这次事故最后靠一次回滚在八分钟内解决。事后我把回滚这块的流程重新捋了一遍，发现很多坑其实是可以提前避开的。这篇就聊聊小程序回滚这件事，不讲大道理，只讲我踩过的和验证过的。

先搞清楚：小程序回滚到底回的是什么

很多人以为回滚就是“把代码退回去”，但小程序有个特殊之处：它跑在用户的微信里，不是你能随时替换的服务器。

• 代码包：用户手机里缓存的是旧版本，新版本发布后是异步更新的，回滚代码包并不能立刻让所有用户回到旧版。
• 后端接口：这才是大多数线上故障的真正源头，回滚后端往往比回滚前端更有效。
• 配置与数据：比如首页的运营位配置、活动开关，这类东西回滚起来最麻烦，因为数据已经写进去了。

所以第一步不是急着点“回退版本”，而是先判断：坏的是哪一层？

我的判断顺序：三分钟定位

故障发生时，我一般按这个顺序排查，基本能在三分钟内确定回滚目标：

1. 看错误监控，确认是新版本发布后才出现的，还是本来就偶发。
2. 看接口错误率，如果后端 5xx 飙了，优先回滚后端服务。
3. 如果后端正常、只有前端白屏，再考虑小程序代码包的问题。
4. 确认是否只有部分用户受影响，这决定了要不要走灰度回退。

经验之谈：先止血，再找原因。线上故障时最忌讳的是边查边改，改着改着就说不清是哪个改动生效了。

代码包回滚的实操

微信开发者工具里可以直接选历史版本重新提交审核，但审核有等待时间，救不了急。真正能救急的是这两招：

1. 用“版本回退”能力

微信公众平台后台的版本管理里，对已发布的版本可以操作回退。注意它回退的是线上版本指向，用户下次冷启动时会拉到旧版本，但不是瞬时的。

2. 用配置中心做开关

这是我更推荐的做法。核心页面入口、新功能都挂一个远程开关，出问题时关掉开关比回滚代码快得多。代码大概长这样：

// 拉取远程配置，失败时走默认安全值
async function getFeatureFlags() {
  try {
    const res = await wx.request({
      url: 'https://api.example.com/flags',
      timeout: 2000
    });
    return res.data || {};
  } catch (e) {
    // 关键：拿不到配置时，默认关闭新功能
    return { newOrderFlow: false };
  }
}

这个默认值千万别写反。我见过有人默认开着新功能，结果配置服务一挂，所有用户都进了未验证的流程。

后端回滚：比想象中重要

大部分小程序的“前端 bug”，根子在后端。接口字段改了、返回结构变了，前端就白屏。所以后端一定要做到：

• 新老接口并存一段时间，前端按版本号取数据；
• 数据库变更用“加字段”而不是“改字段”，回滚时旧代码还能跑；
• 发布前把回滚命令写进发布单，别等出事再翻文档。

我现在习惯在发布脚本里留一行注释，写清楚回滚到上一个 tag 的命令。别小看这一行，凌晨两点脑子是转不动的。

灰度发布是回滚的前置条件

没有灰度，回滚就是全量事故。微信小程序本身没有原生的灰度能力，但可以自己做：

• 按用户 openid 哈希分桶，先放 5% 用户进新逻辑；
• 新功能入口先对内部账号可见；
• 观察 24 小时错误率和核心转化，再逐步放量。

灰度期间一旦指标异常，直接把分桶比例调回 0，比回滚代码包快得多，用户也几乎无感。

最后说几句

回滚能力不是发布之后才考虑的，它应该在写第一行业务代码时就想好。我的原则是：任何一次发布，都要能在五分钟内退回上一个稳定状态，并且这个动作不需要临时思考。

那次白屏事故之后，我给自己的项目加了两样东西：一个远程开关中心，一份写在发布脚本里的回滚清单。之后再没熬过那种夜。希望你也不用。