移動端發佈比網頁多一層不可控因素：用戶不會同時升級安裝包。新伺服器、舊 App、緩存中的本地數據和可能存在的 JS 更新會在真實環境中共存。發佈門禁首先要驗證這些組合，而不只是 CI 里能構建成功。
分清交付邊界
原生依賴、權限聲明、平台配置變化必須進入新的安裝包；支援熱更新的方案也只能在兼容的運行時邊界內更新可交付代碼。每次發佈記錄應用版本、構建號、運行時標識、伺服器兼容範圍和遷移版本。後端新增欄位盡量向後兼容，刪除欄位要先觀察舊客戶端佔比。
灰度看業務指標
先驗證安裝、啟動、登入、關鍵交易與通知跳轉，再逐步擴大人群。只看崩潰率會漏掉「沒有崩潰但無法下單」。把錯誤率、請求超時、同步積壓、訂單完成率與版本號關聯，設置明確的暫停閾值。若問題來自伺服器開關，優先關閉功能；若來自本地數據庫不可逆遷移，回退安裝包也未必能恢複數據，需要預先設計向前修復路徑。
發佈記錄要能回答：誰受影響、如何復現、回滾哪一層、恢復後如何確認數據正確。RN 和 Flutter 的具體工具不同，這套決策鏈相同。
用一次支付流程改版設計放量
假設新版本改動了支付確認頁、客戶端本地狀態和服務端請求字段。發版前先列出版本兼容矩陣：舊客戶端配新服務端能否繼續支付，新客戶端配舊服務端會怎樣，更新失敗時能否回滾。服務端先兼容新增字段，再發佈客戶端；破壞性字段刪除要等舊版本退出支持範圍。對於通過遠程更新分發的 JS 資源或配置，還必須遵守對應平台和商店規則，並核對原生二進制與資源版本的兼容性。
放量以可觀測的門檻推進。先內部設備，再小比例真實用戶，再逐步擴大；每一檔都記錄樣本量、支付完成率、崩潰和 ANR、關鍵頁面錯誤、API 拒絕比例。閾值要按業務基線和流量設定，不能憑一個固定百分比套所有應用。低流量時不要僅憑“零崩潰”放行；可以結合人工回歸、合成交易與更長觀察窗口。
內部驗證 → 小流量觀察 → 比較同版本/同地區基線 → 擴大流量
↘ 超出門檻：停止擴量、回滾可回滾部分
回滾必須有明確的對象
服務端 feature flag 可以關掉新入口，遠程資源可以回退到與當前二進制兼容的版本，但商店分發的原生二進制通常不能瞬間撤回到舊版。若數據庫已經遷移或用戶已提交新格式數據，回滾前要確認舊代碼仍能讀取。發佈記錄應標出負責人、觀測儀錶盤、停止條件和回滾命令；演練一次關開關、恢復服務端兼容路徑和處理已產生的訂單。參考：Expo EAS Update 部署。