企业App出问题，很少是“代码写错一行”那么简单，而是错的版本已经到了足够多的人手里。Google Play官方帮助写明：分阶段发布（staged rollout）只适用于更新，不适用于首次上架；百分比不会自动增加，需要发布负责人手动扩大。Apple开发者文档则把更新叫作分阶段推出（phased release）：对开启自动更新的用户，按7天固定节奏放量，1%、2%、5%、10%、20%、50%，最后到100%。两边都在做同一件事——把爆炸半径锁在可回撤的窗口里。
一、两套商店，两套灰度语法
Bitrise对发布管理的对照很清楚：Apple不让你手改百分比，但允许在最多30天内多次暂停；恢复后从暂停那天继续，而不是重头计算。Play更灵活，间隔和比例自己定，却有一条硬约束——不能把已经放大的百分比往回调，只能“中止”。中止后，已经升上新版本的用户继续留在新版本，只是不再有新用户进入该批次。若应用从架上撤下或开发者计划过期，Apple的分阶段会停止，重新上架后会立刻对所有人可见，想再控量只能重新提审一个版本。
| 维度 | Google Play 分阶段发布 | App Store 分阶段推出 |
|---|---|---|
| 适用 | 更新包，首次发布不可用 | 已上架应用的版本更新 |
| 节奏 | 人工上调百分比，无强制7天 | 7天自动：1→2→5→10→20→50→100 |
| 暂停 | Halt后不再扩散，已升级用户保留新包 | 累计可暂停30天，次数不限 |
| 回退比例 | 不允许降低，只能中止或发新包 | 不能手改比例，要全量只能提前放开 |
| 国家/地区 | 可先限定国家，开始后不能再删国家 | 跟随现有销售范围 |
二、崩溃率必须写成“过不去就停”的门禁
Luciq《2025 Mobile App Stability Outlook》给出的行业中位数是会话无崩溃率99.95%，头部团队能到99.99%。多数团队把放量门槛放在99.5%到99.9%之间，金融和医疗更靠上沿。实践上不要只看绝对值，还要和上一版本比：任何阶段出现崩溃率翻倍，或ANR持续超过0.5%，都该中止而不是“再观察一晚上”。Play还提醒：分阶段用户可以公开写评价，差评浪潮比崩溃曲线更早伤品牌。
2.1 企业包还有一层MDM
走商店的消费级灰度，解决不了“只给现场工程师更新”的问题。企业内部分发常见三条路：商店公开版走官方灰度；员工版走TestFlight / 内部测试轨道；现场加固包走MDM强制版本。门禁要按轨道分别设：公开版看崩溃与评分，内部版看关键流程是否跑通，MDM包还要看证书、设备绑定和是否允许降级。把三条轨道混成一次“全员推送”，出问题会同时打到客户、销售和车间。
三、热修复不是第二套应用商店
原生崩溃、权限模型、支付SDK、系统WebView变更，只能打新二进制走审核。跨端框架的JS/Dart业务层，可以用EAS Update、CodePush一类通道做OTA。安全边界要写进制度，而不是写进口号：
- 允许OTA：文案、布局、非关键业务逻辑、已在商店包里预埋的开关。
- 禁止OTA：权限声明、隐私清单、支付与登录内核、越狱检测、证书钉扎。
- 必须重新提审：原生崩溃、系统API行为变化、商店政策点名的能力。
企业客户常高估热修复。一次“凌晨推脚本”如果改到了鉴权或采集字段，等于绕过了应用商店与法务审查。合同和运维手册应写明：OTA有名单、有审计、有一键关闭；关闭后设备必须能回到商店包的确定版本。
四、一份能挂在墙上的放量卡片
发布当天不该靠聊天群里的感觉。建议做成一页卡片：当前百分比、无崩溃率、ANR、启动耗时、关键转化、差评条数、负责人、中止按钮在哪个控制台。Play侧记得商店素材尽量等100%再改，避免半量用户看到对不上的截图。Apple侧如果决定提前全量，要意识到这是不可逆地放弃剩余节奏。原生包修不了的致命缺陷，Apple提供加急审核通道，Play的常规审核通常更快，但两条通道都要求重新提交二进制，不能把已经中止的旧包百分比往回拧。
现场作业类App还要单独看弱网：灰度样本若全是办公室Wi-Fi，崩溃率漂亮也不能代表车间。把测试轨道里的设备画像写进门禁，比只看全球平均值更接近企业场景。热修复通道如果当天必须动用，事后要补一条“为何没能在二进制里修好”的回顾，防止OTA变成默认发布方式。
企业App的发布门禁，本质是承认“新版本默认不可信”。灰度买的是观察时间，崩溃率买的是停手的权力，热修复买的是补丁通道而不是法外之地。下一次版本会如果还在争论“要不要灰度”，把这张卡片打印出来：谁有权Halt、数字到多少必须Halt、Halt之后多长时间内必须给出新二进制。讨论清楚这三句，比再加两个功能更保护现场。