CodePush 替代方案与 Pakta 迁移指南
App Center CodePush 退役后，对比独立 CodePush、EAS Update 与 Pakta，按 SDK、原生包、渠道和恢复流程规划迁移。
更新于 2026-09-15
App Center CodePush 退役后用什么？
Pakta 是面向愿意更换更新 SDK、重新发布原生包的团队的一种 React Native OTA 方案。它不是即插即用的 CodePush 服务端：rn-update、.ppk 制品以及 Pakta 的应用和渠道定向遵循不同的接入契约。只更换 deployment key，不能让原有 CodePush 安装包接收 Pakta 更新。
Microsoft 已于 2025 年 3 月 31 日退役 App Center CodePush，同时发布了独立服务端。因此，托管服务退役不代表所有基于 CodePush 的方案都已消失。参见退役公告与独立 CodePush 服务端。
比较迁移路径
| 路径 | 需要改变什么 | 需要验证什么 |
|---|---|---|
| 独立 CodePush | 托管环境、服务地址，可能还有客户端配置 | 服务端运维及具体 SDK/运行时兼容性 |
| Expo EAS Update | 接入 expo-updates，改用 EAS 工作流 | 原生接入、runtime version 与渠道 |
| Pakta | 接入 rn-update，登记原生基线并发布 .ppk | 原生接入、目标身份与设备恢复 |
Microsoft 原版 React Native CodePush 仓库已经归档，并明确不支持新架构。如果保留 CodePush 客户端，需要逐项核对具体分支和版本。选择 Expo 路径时，遵循 Expo 官方迁移指南。
改代码前先映射概念
| CodePush 概念 | Pakta 工作流 | 迁移影响 |
|---|---|---|
| Deployment key | 应用 appKey 与原生渠道身份 | 凭据与标识不能直接复用 |
| 目标二进制版本 | 已登记原生包与渠道/版本目标 | 先登记新的准确安装包 |
| 发布 bundle | CLI 生成的 .ppk | 从源码重新构建，不上传旧 CodePush 制品 |
| 安装模式与就绪通知 | 更新策略与健康确认 | 重新检查生效时机和启动健康行为 |
| 灰度与回滚 | 目标比例与恢复投放 | 验证设备行为，不能只看控制台状态 |
这是工作流映射，不是 API 兼容声明。实际契约见 SDK 接入与渠道配置。
分阶段迁移到 Pakta
盘点 React Native 版本、原生模块、Hermes 配置、已安装二进制版本、deployment key 和启动钩子。保留最近稳定版源码与 sourcemap。
在迁移分支中移除 CodePush 的 JavaScript 包装与原生 bundle 加载接入。按 Pakta 原生配置或 Expo 配置完成接入，让一个更新系统负责 bundle 选择。
按平台创建 Pakta 应用。配置内部原生渠道，接入根 Provider、生效策略与健康确认。
构建并安装新的 Release 二进制，按首次发布流程登记这份准确的 APK/IPA。
向内部渠道发布一处文案更新。检查更新 hash、冷启动、离线启动和恢复稳定包的行为。
按正常发版流程分发新的原生包。把新包安装覆盖率与旧 CodePush 用户群分开统计，再逐步向新包发布兼容的 Pakta 更新。
已安装旧版本的用户怎么办？
只包含 CodePush 的 App 需要升级原生包才能包含 rn-update。这些设备不能计入 Pakta 可投放范围。为尚未升级的用户保留明确的处理方案，包括其现有安装包实际支持的恢复路径。
取消 Pakta 灰度不会移除已经安装的更新。首次生产投放前先阅读恢复行为。
怎样做出选择？
保留客户端协议、采用 Expo 更新生态、选择 Pakta 发布工作流，是不同的需求。生产迁移前先用一份 Release 包跑通完整链路。继续阅读 React Native OTA 基础、Expo Updates 与 Pakta 对比或快速开始。