不知道你们有没有留意过，微信每次更新版本时，更新日志几乎都是同一句话：「-解决了一些已知问题。」不管是上线了新功能，还是做了大大小小的优化，永远都是这短短几个字。

以至于每次更新微信，都有点像开盲盒。因为你不知道，这次更新是真的修复了几个 Bug，还是悄悄藏了一个新功能。甚至，有时候明明用着最新版，新功能还是通过热心网友得知的；当然，也有可能明明已经是最新版本了，别人有的功能，你却没有。

比如前阵子引发热议的微信原生AI助手‘小微’，当无数网友晒出首页左上角那双‘绿色眼睛’时，很多满怀期待去升级的用户却发现，自己的微信依然是老样子。

同样都是最新版微信，为什么别人有，我却没有？不是你更新失败了，也不是手机系统的差异，更不是微信偷偷把你忘了。只是因为这次内测，还没有轮到你。

实际上，不只是微信，几乎所有大型互联网 App 在上线新功能时，都不会一次性开放给所有用户，而是逐步开放。至于哪些人能提前体验？为什么有人有、有人没有？为什么有的功能昨天还在，今天却突然消失了？这些背后其实都有一套成熟的发布策略。

今天，我们聊聊App 新功能到底是怎么一步步「放出来」的。

新功能为什么不是一起上线？

假设你是微信的开发人员，今天终于把一个新功能开发完成，你会怎么发布？可能你会想，那不是直接一次性推给所有用户就行么？听起来好像很合理，但现实中，一般不敢这么做。

对于程序员来说，开发完成，并不代表结束，上线才是真正的开始。再充分的测试，也不可能模拟几千万、上亿用户同时使用的真实环境。开发时测试一切正常，不代表上线以后不会出现意外。手机型号不同、系统版本不同、网络环境不同，甚至一个测试阶段从来没有出现过的小 Bug，都可能因为几千万用户同时使用，被瞬间放大。如果一上来就开放给所有用户，一旦出了问题，后果很严重。

所以，对于大型互联网公司来说，“一次性全量上线”反而是风险最高的做法，更稳妥的做法是先让少部分用户体验，确认没有问题之后，再逐渐扩大范围；如果发现 Bug，就暂停继续放量，甚至直接关闭新功能。这样，即使出现问题，也只会影响很小一部分用户。我们把这种方式称为灰度发布。

灰度通常有两个阶段：一是你什么时候可以更新APP；二是新功能什么时候真正开放给你。

通过应用市场决定你什么时候收到新版本

我们都会遇到过这样的情况，某个 App 明明其他人已经更新到了最新版，可是自己打开App Store或者应用市场搜索时却发现：根本没有"更新"按钮。这是因为应用市场本身也可以做灰度发布。

以苹果的 App Store 为例，开发者可以选择让新版分阶段发布，系统在‌7 天内‌按固定比例（1%→2%→4%→10%→25%→50%→100%）向‌已开启自动更新‌的现有用户随机推送；‌期间可‌暂停‌（最多 30 天）或‌提前全量‌，但‌无法回滚‌且‌无法指定人群‌。Google Play、各大安卓应用市场，也都有类似的发布机制。这样做最大的好处就是：如果新版出现了严重 Bug，可以及时暂停继续推送，而不是让所有用户一起“踩坑”。

所以，有时候别人已经更新到了最新版，而你的 App Store 依然没有提示更新，并不是你的手机出了问题。只是新的安装包，还没有推送到你这里。

更新了，也不一定马上有新功能

安装包更新完成以后，APP还可以进行第二轮灰度，也就是——功能灰度。

APP服务器可以控制新功能给哪些用户体验。所以会出现你和朋友都更新到了同一个版本，版本号完全一样，但功能不一样。就像文章开头提到的微信「小微」，很多用户已经升级到了最新版微信，却依然没有看到入口。

如何决定哪些人先体验，哪些人后体验

既然不是所有人一起体验新功能，那应该如何选择体验的人群。也许大部分人会想到随机抽取，确实可行。但随机只是其中一种方式。对于不同的新功能，往往采用不同的放量策略。

第一种：按比例放量

这是最常见，也是最容易理解的一种方式。假设一个 App 有 1000 万用户，第一天，开放给 1% 的用户；如果没有发现问题，第二天扩大到 10%；接着是 30%、50%，最后再开放给全部用户。这个和前文说的应用市场控制安装包分发的时机类似，只不过是由APP服务器自行控制。

第二种：按设备放量

有时候，你有没有新功能，看的不是账号，而是手机。比如先开放给 iPhone，或者先开放给安卓，甚至只开放给某几个品牌。因为同一个 App，在不同手机上的表现其实并不完全一样。有时候需要选择一部分设备进行验证，确认没有兼容性问题，再逐渐扩大到更多机型。

第三种：按地区放量

除了设备，地区也是一个常见的放量条件。例如先开放给深圳，再扩大到广东，最后全国上线。

一方面，可以观察不同地区用户的反馈，另一方面，也能避免服务器一下子承受过大的访问压力。特别是一些需要大量服务器资源的新功能，逐步开放，比全国同时上线更加稳妥。

第四种：按用户类型放量

简单来说就是“挑人”，根据用户的使用习惯来决定。

例如：

经常使用某个功能的人。

活跃度比较高的用户。

参与过测试计划的用户。

甚至互联网公司的内部员工。

这些人使用频率高，遇到问题的概率更高，也更愿意主动反馈。程序员就能更快发现 Bug，并及时修复。所以，有时候你会发现，越是重度用户，越容易提前体验到一些新功能。

第五种：按下载渠道放量

即使安装的是同一个 App，不同渠道下载的版本，也可能属于不同的体验组。举个例子，有的人是在 App Store 下载的，有的人是在华为应用市场，有的人是在小米应用商店，还有的人是官网下载。虽然安装的是同一个 App，但后台完全可以针对不同渠道，采用不同的放量策略。比如：先开放给 App Store 用户，观察几天，没有问题，再开放给其他应用市场。这样，即使某个渠道出现兼容问题，也不会影响所有用户。

不过，有时候即使所有人都已经更新到了最新版，也都进入了同一轮灰度，大家看到的页面仍旧可能不一样。这又是另一种完全不同的机制--A/B 测试，它不是为了测试稳定性，而是为了验证：到底哪一种设计，更受用户欢迎。

假设某个购物 App 想知道："立即购买"按钮放左边好，还是放右边好？产品经理不知道，设计师不知道，程序员也不知道。那怎么办？最公平的方法就是交由用户去抉择。

此时可以同时上线两个版本。一部分用户看到 A 方案，另一部分用户看到 B 方案。然后统计数据：哪个点击率更高？哪个下单率更高？哪个停留时间更长？数据会告诉大家答案。最后，再把效果更好的方案推广给所有用户。

为什么昨天还有，今天突然没了？

有时候某个功能或者入口明明昨天还能有，今天突然找不到了。是不是 App 出 bug，未必。

现在很多 App 的功能，并不是完全写死在安装包里的。真正决定它们是否显示的，往往是服务器后台。可以把它理解成一个"总开关"，当服务器把开关打开，符合条件的人都能看到；明天关闭开关，功能立刻消失。这种方式不用重新发布 App，用户也不用更新版本。

这样做有两个好处。第一，如果发现新功能存在 Bug，可以第一时间关闭，把影响控制到最小。第二，运营活动、节日功能、限时入口，也都可以按计划自动开启和关闭。

所以，有时候你发现某个功能突然消失，不一定是 Bug，很可能只是后台把这个开关暂时关掉了。

为什么做这么麻烦的分发策略？

看到这里，你也许会觉得为了上线一个功能，至于搞这么复杂吗？其实，真的至于。

为了实现灰度发布，需要额外开发灰度系统，产品和运营需要制定放量策略，测试需要同时验证多个版本，后台还要维护不同用户对应不同的配置。这些都会增加不少开发和维护成本。对于只有几千、几万用户的小应用来说，这样做未必划算。所以很多小团队会直接全量上线新功能，但对于拥有几千万、上亿用户的平台来说，一次线上事故造成的损失，往往远远超过这些成本。所以，大厂宁愿把上线流程做得复杂一点，也要尽可能把风险降到最低。

写在最后

一个新功能从开发完成，到最终出现在每个人手机上，中间可能经历了无数次小心翼翼的“试探”。有人先体验，有人后体验，有人帮忙发现 Bug，有人参与 A/B 测试，还有人在毫不知情的情况下，成为新功能的第一批"尝鲜者"。

程序员最朴素的愿望是每一次上线，都尽可能平稳、安全。

愿世界少一点 Bug，愿每一次发布都顺顺利利，不用随时随地修 Bug～