小程序上线后的版本管理与灰度发布

小程序改完提交，要经过审核才能上线，这个机制决定了发版的节奏和风险都跟网页不一样。发出去之后发现问题，不能像改了网页那样立刻改回来。

把发版当成一个有流程的动作，能少出很多状况。

一、版本机制要理清

小程序有几个版本状态，开发版给开发者自己用，体验版给测试和少量人用，正式版给所有用户。提交审核的是从体验版提交，审核通过后发布为正式版。

这中间有个容易误解的点，审核通过不等于立刻对所有用户生效。用户在下次打开小程序时会更新到新版本，但已经打开的可能还在用旧版。所以新版本发布之后，一段时间内新旧版本是并存的。

正因为并存，接口兼容就很重要。新版本用的接口要提前部署好，旧接口在过渡期内不能停。这个过渡期一般留一到两周。

二、灰度怎么做

小程序本身没有像网页那样按比例放量的灰度机制，但可以做变相的灰度。

一种做法是在功能层面做开关。新功能写完先不打开，正式版上线后通过服务端的配置控制开关，先对内部人员开启，观察几天没问题再对全部用户开启。这样即便新功能有问题，关掉开关就能恢复。

另一种做法是先发体验版给一批人用。找十个二十个真实用户，让他们用体验版跑几天，反馈问题。这批人最好覆盖不同机型和不同使用习惯。

涉及数据结构变化的版本要更谨慎。这类改动一旦上线，回滚就不只是换代码的事。建议把结构变动的部分拆成两步，先上线兼容旧结构的版本，确认稳定之后再上真正使用新结构的版本。

三、发现问题怎么快回滚

小程序有一个版本回退的能力，可以把正式版切回上一个版本。这个操作很快，但要注意配套处理。数据库的变动没法跟着回退，所以如果新版本改了数据结构，回退代码之后可能跟数据对不上。

更可靠的做法是尽量用功能开关控制。关开关比回退版本快，也不用等生效时间。凡是风险较高的改动，都建议配上开关。

回滚的决策要有明确的责任人。出现问题的时候，如果还要一层层请示谁来定，耽误的时间可能比问题本身的影响大。提前约定好什么情况下可以直接回滚，谁来拍板。

四、发布节奏怎么安排

提审要留出审核时间。审核的时长不固定，赶上高峰期或者节假日会更久。重要版本要提前几天提审，不要卡在活动前一天。

不要频繁发版。每次发版都有风险，也有审核不通过的可能。把改动攒一攒，固定节奏发布，比如两周一次。紧急修复可以单独走，但要有理由。

每次发版前准备一份自检清单。核心流程走一遍、支付和登录这类关键功能测一遍、不同机型看一遍、旧版本是否还能正常使用确认一遍。清单固定下来，每次照着走，比凭记忆可靠。