一次性把更新推给所有用户，是一个无法撤销的决定。Google Play 的分阶段发布（staged rollout）把这个决定变成一个旋钮：先只推给一部分用户，观察 Android vitals，再在正式版页面决定放量还是叫停。到了 2026 年，这个能力已经不止于「比例滑块」——已经推给 100% 用户的版本现在也可以暂停，并由上一个在线的正式版自动顶替。本文完整梳理全流程：选择比例、限定国家/地区、逐步放量、暂停发布、暂停已全量发布的版本、恢复发布，以及修复必须落到代码时如何用新版本号交付。
分阶段发布到底控制什么
它比「先推给一部分用户」更具体，这些差别直接决定出事时该怎么处理：
- 仅用于更新。 首次发布应用时不能使用分阶段发布——首次发布不会出现放量比例选项。
- 控制的是「资格」，不是「实际送达」。 更新只会提供给所选比例的用户，整个群体收到更新可能需要时间，而且用户不会收到任何「你正在灰度中」的通知。
- 每次发布随机选取。 新用户和现有用户都有资格，并在每次新发布放量时被随机选中。
- 暂停只是止血，不会回滚。 暂停后不会再有新用户收到该版本，但已经安装的用户会继续停留在该版本。
- 恢复发布针对同一批用户。 暂停后再次恢复同一个发布，影响的仍是同一组用户。
在 Play Console 的什么位置
比例是在你要发布的目标轨道页面上设置的：正式版更新走 测试和发布 > 正式版，测试轨道走 开放测试 / 封闭测试 页面。创建发布需要「将应用发布到测试轨道」权限，正式版发布还需要管理正式版发布的权限——看不到轨道页面或看不到放量控件时，先查权限。
- 内部测试——最多 100 名指定测试人员，最快的一环，也是唯一不支持「暂停已全量发布版本」的轨道。
- 封闭测试——在一条或多条自定义轨道上的有限测试人员。
- 开放测试——测试人员可以直接从商品详情页加入。
- 正式版——你所选国家/地区内的全部用户。
动手之前还有一条硬性前提：存在未完成的发布时，无法创建新发布。需要先把分阶段发布推到 100%，或在「发布概览」页面移除待送审的改动并丢弃未发布的版本。
开始一次分阶段发布：操作步骤
- 在 Play Console 中打开目标轨道：测试和发布 > 正式版，或开放/封闭测试页面。
- 进入 发布 标签页，点击 创建新发布；已有发布则点 修改发布。按钮不可点，通常是「信息中心」还有未完成的设置项。
- 上传应用包、填写发布名称，并撰写「本次更新内容」——每个语言最多 500 个 Unicode 字符，各语言需写在独立的语言标签内、标签单独成行。
- 点击 下一步 进入预览与确认页，清空「错误摘要」中列出的所有问题。
- 在 分阶段发布 区域填写放量比例。这个比例不会自动提高。
- 可选：在 国家/地区可用性 中限定范围——该选项仅在更新正式版发布时出现。
- 点击 开始发布（正式版为 开始发布到正式版）。
限定国家/地区的分阶段发布
分阶段发布可以先只覆盖部分国家/地区，默认范围与正式版轨道已配置的地区一致。这里有一个单向的坑：分阶段发布一旦开始，就无法再移除任何国家/地区。 因此初始范围要按「只会扩大、不会缩小」来选。
如何提高放量比例
在轨道页的 发布 标签下找到该发布，选择 管理发布 > 更新发布，填写新的比例，点击 确认更新。放量完全依靠手动：你不改，它就永远停在上一次设定的比例上。
把比例理解为「只增不减的节奏」，而不是可以来回拖动的滑块。调低比例不会让已经收到更新的用户退回旧版，改变的只是此后谁有资格收到。如果目标是停止扩散，请用「暂停发布」，而不是把比例调回去。
暂停分阶段发布
如果发现问题且放量尚未完成，就暂停它：在轨道页的 发布 标签下选择 管理发布 > 暂停发布。此后不会再有新用户收到该版本，已经收到的用户会停留在该版本。暂停是控制影响面，不是回滚——该版本仍留在已安装的设备上，客服可能要同时面对两个版本。
暂停已经全量发布的版本
Play 也允许暂停已经推送到 100% 用户的版本，这正是过去无法处理的场景。被暂停的版本将不再下发，一个此前在线、已完成全量发布的版本会自动顶替它，面向新用户和符合条件的用户开放。规则与限制如下：
- 除内部测试外的任意轨道均可操作，可通过 Play Console 网页版、移动端应用或发布 API 执行。
- 恢复时可选择任意比例——这正是修复后逐步重新放开的方式。
- 不能暂停某条轨道的首个版本。 如果当前 100% 的发布是该轨道上的第一个版本，就没有可回退的历史版本。
- 存在政策违规的历史版本不能被顶替使用。
- 暂停得太晚效果有限。 如果该版本已上线很久或覆盖了大多数用户，多数人其实早已更新到被暂停的版本。
故障恢复：恢复发布，还是交付修复包
停下之后只有两个方向，选错就浪费一轮：
- 恢复发布——包本身没问题时使用。服务端事故、单个崩溃簇造成的误报、已在服务端修好的问题，都不需要新包：管理发布 > 恢复发布，选择比例，确认更新。暂停后恢复，影响的仍是同一组用户。
- 发布新版本——包本身有问题时必须如此。用修复后的包创建新发布，并使用更高的版本号。Google Play 没有降级通道：商店只下发版本号最高的包，所以「回滚」永远意味着把旧代码重新打包，用一个新的、更高的版本号再发一次。
还要注意连续发布之间的相互作用：如果上一个发布还没放完就开始了新发布的分阶段发布，新发布会沿用上一个发布的那组用户（取决于其比例）。也就是说，重叠的放量窗口并不会像开发者预期的那样扩大测试人群。
放量期间该盯哪些数据
- 发布概览——安装量、更新量、性能问题和评分与历史版本的对比。
- Android vitals——崩溃率与 ANR 率是决定「继续放量还是暂停」的两个核心信号，应与上一个版本对比，而不是对照某个固定阈值。
- 发布历史——记录该发布何时被暂停、恢复、以及放量到新比例的时间线，这是事故复盘时唯一的审计轨迹。
- 评分与评论——灰度中的用户也可以留下公开评论，因此 5% 的曝光也足以在详情页上留下一条 1 星评价。
- 商品详情的改动——不要和放量发布混在一起。Google 建议等发布覆盖到 100% 用户后再更新商品详情。
最耗时间的常见坑
- 以为比例会自动往上走，一周后才发现发布还停在 5%。
- 把 100% 当作终点。现在 100% 也可以暂停，但前提是有合规的历史版本可以顶替。
- 试图用旧包、旧版本号「回滚」。Play 会直接拒绝，版本号必须递增。
- 忘记被暂停的版本仍留在已安装的设备上，客服需要同时支持两个版本。
- 在分阶段发布里加了国家/地区，之后才发现开始后无法移除。
- 放量途中修改商品详情，导致详情页与大多数用户手上的版本不一致。
- 几十个应用全手工放量。发布 API 的轨道对象提供
userFraction，设置比例、暂停与恢复都可以脚本化并留痕。
一句话模型： 分阶段发布控制的是「谁有资格收到更新」，而不是设备上已经装了什么。分批提高比例，每一步之前先看 vitals，用暂停止住新增曝光，用恢复覆盖回同一批用户；当修复必须落到代码时，发布一个版本号更高的新版本。100% 不再是死局，但兜底的是你的上一个正式版，而不是那个出问题的版本。