移动端发布比网页多一层不可控因素：用户不会同时升级安装包。新服务端、旧 App、缓存中的本地数据和可能存在的 JS 更新会在真实环境中共存。发布门禁首先要验证这些组合，而不只是 CI 里能构建成功。
分清交付边界
原生依赖、权限声明、平台配置变化必须进入新的安装包；支持热更新的方案也只能在兼容的运行时边界内更新可交付代码。每次发布记录应用版本、构建号、运行时标识、服务端兼容范围和迁移版本。后端新增字段尽量向后兼容，删除字段要先观察旧客户端占比。
灰度看业务指标
先验证安装、启动、登录、关键交易与通知跳转，再逐步扩大人群。只看崩溃率会漏掉“没有崩溃但无法下单”。把错误率、请求超时、同步积压、订单完成率与版本号关联，设置明确的暂停阈值。若问题来自服务端开关，优先关闭功能；若来自本地数据库不可逆迁移，回退安装包也未必能恢复数据，需要预先设计向前修复路径。
发布记录要能回答：谁受影响、如何复现、回滚哪一层、恢复后如何确认数据正确。RN 和 Flutter 的具体工具不同，这套决策链相同。
用一次支付流程改版设计放量
假设新版本改动了支付确认页、客户端本地状态和服务端请求字段。发版前先列出版本兼容矩阵：旧客户端配新服务端能否继续支付，新客户端配旧服务端会怎样，更新失败时能否回滚。服务端先兼容新增字段，再发布客户端；破坏性字段删除要等旧版本退出支持范围。对于通过远程更新分发的 JS 资源或配置，还必须遵守对应平台和商店规则，并核对原生二进制与资源版本的兼容性。
放量以可观测的门槛推进。先内部设备，再小比例真实用户，再逐步扩大；每一档都记录样本量、支付完成率、崩溃和 ANR、关键页面错误、API 拒绝比例。阈值要按业务基线和流量设定，不能凭一个固定百分比套所有应用。低流量时不要仅凭“零崩溃”放行；可以结合人工回归、合成交易与更长观察窗口。
内部验证 → 小流量观察 → 比较同版本/同地区基线 → 扩大流量
↘ 超出门槛：停止扩量、回滚可回滚部分
回滚必须有明确的对象
服务端 feature flag 可以关掉新入口，远程资源可以回退到与当前二进制兼容的版本，但商店分发的原生二进制通常不能瞬间撤回到旧版。若数据库已经迁移或用户已提交新格式数据，回滚前要确认旧代码仍能读取。发布记录应标出负责人、观测仪表盘、停止条件和回滚命令；演练一次关开关、恢复服务端兼容路径和处理已产生的订单。参考：Expo EAS Update 部署。