小程序版本迭代，别把老用户当测试机

上周去望京见一个做连锁烘焙的客户，老板见面第一句话不是聊需求，而是把手机递过来：“你帮我看看，我们这个小程序更新完，老会员的储值余额显示不出来了。”我打开一看，版本号确实是最新的，但登录态还是旧缓存，接口返回的字段名在上个版本里改过，前端没做兼容。这种事在北京做小程序这行里，几乎每周都能碰到。

版本迭代这件事，写代码的人觉得是发个版，做运营的人觉得是上个新功能，但对用户来说，它是一次“你动了我正在用的东西”。今天这篇就聊聊知码客在给北京本地客户做迭代时踩过的坑和总结的几条规矩。

先想清楚：这次迭代到底改的是什么

很多团队一上来就排需求、拉分支，其实第一步应该是分类。我们内部把迭代分成三类：

• 修复型：线上 bug、兼容性问题、支付回调异常。这类要快，走紧急通道，能当天发就不拖到明天。
• 增强型：加个优惠券模块、改改订单流程。这类要稳，必须经过完整回归。
• 重构型：换框架、拆包、改数据模型。这类要慢，而且必须做灰度。

分类不清楚，最直接的后果就是把修复型当增强型排期，客户等一周，投诉电话打到老板那里。我们在给朝阳一家做社区团购的客户做迭代时，就吃过这个亏——一个下单页面的兼容问题被排进了两周后的版本，结果那两周的退款率翻了一倍。

兼容旧数据，比写新功能更费心

小程序和原生 APP 不一样，用户没有“必须更新才能用”的强制力，微信的更新机制是异步的，有人第二天才拿到新版本，有人甚至几个月不更新。所以后端接口必须同时伺候好几个版本的前端。

我们的做法是接口字段只增不删，废弃字段先标记，观察两三个版本再下掉。返回结构里加一个 version 字段，前端按版本做降级渲染。举个实际例子：

// 旧版本前端可能只认 goodsName
// 新版本改成 title，那就两个都给
{
  "code": 0,
  "data": {
    "goodsName": "提拉米苏",
    "title": "提拉米苏",
    "version": "2.3.0"
  }
}

看着笨，但真能救命。北京这边不少客户是线下门店和线上小程序并行，收银系统和后台数据对不上，排查半天最后发现是旧版本小程序还在提交老格式的订单。

灰度发布，别一次全量推

微信小程序支持分阶段发布，但很多人图省事直接全量。我们的建议是：涉及支付、登录、订单这三块的改动，一律先放 10% 到 20% 的流量，观察 24 小时。

观察什么？不是看有没有崩溃，而是看几个业务指标：支付成功率、下单转化率、页面停留时长。有一次我们给海淀一个教育机构做课程预约迭代，灰度期间发现预约成功率掉了 8%，查下来是新加的日期选择组件在部分安卓机型上默认值没带上，全量推的话就是一次事故。

灰度不是走流程，是给自己留一个“后悔药”的窗口。窗口关了就没了。

上线前后的清单，比记性靠谱

迭代多了就会发现，出问题的往往不是难的技术点，而是忘了一件事。我们现在固定跑一份清单：

1. 数据库变更脚本是否在预发环境跑过，回滚脚本有没有准备；
2. 小程序后台的服务器域名、业务域名有没有新增；
3. 隐私协议、用户授权文案是否随功能更新；
4. 版本号和体验版是否对应，别发错包；
5. 上线后半小时内盯一次核心接口的报错率和耗时。

第 3 条特别容易被忽略。去年给丰台一个做家政预约的客户迭代时，新增了手机号快捷登录，结果隐私协议没同步更新，审核被驳回一次，白白耽误三天。北京这边平台审核对授权合规查得比较细，这块真不能省。

迭代节奏，要和客户的生意节奏对齐

技术上的节奏是一回事，生意上的节奏是另一回事。餐饮客户周五到周日是高峰，迭代就别排周四晚上；零售客户大促前两周，只允许修 bug，不允许上新功能。我们给通州一个做生鲜的客户定过一条规矩：大促前 14 天冻结功能发布，只留热修复通道。这条规矩救过他们一次双十一。

知码客一直说“知码识途、匠心铸客”，落到版本迭代上，其实就是两句话：知道代码往哪走，也知道客户的生意经不起折腾。每一行代码都是和用户沟通的语言，那版本迭代就是一次对话——话说得太急、太糙，用户是能听出来的。

如果你也在北京做小程序，正卡在迭代节奏或者老版本兼容上，欢迎来聊聊，很多坑我们都替你踩过了。