企業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之後多長時間內必須給出新二進制。討論清楚這三句，比再加兩個功能更保護現場。