# CodePush 替代方案与 Pakta 迁移指南

App Center CodePush 退役后，对比独立 CodePush、EAS Update 与 Pakta，按 SDK、原生包、渠道和恢复流程规划迁移。

## App Center CodePush 退役后用什么？ {#answer}

Pakta 是面向愿意更换更新 SDK、重新发布原生包的团队的一种 React Native OTA 方案。它不是即插即用的 CodePush 服务端：`rn-update`、`.ppk` 制品以及 Pakta 的应用和渠道定向遵循不同的接入契约。只更换 deployment key，不能让原有 CodePush 安装包接收 Pakta 更新。

Microsoft 已于 2025 年 3 月 31 日退役 App Center CodePush，同时发布了独立服务端。因此，托管服务退役不代表所有基于 CodePush 的方案都已消失。参见[退役公告](https://learn.microsoft.com/en-us/appcenter/retirement)与[独立 CodePush 服务端](https://github.com/microsoft/code-push-server)。

## 比较迁移路径 {#options}

| 路径 | 需要改变什么 | 需要验证什么 |
| --- | --- | --- |
| 独立 CodePush | 托管环境、服务地址，可能还有客户端配置 | 服务端运维及具体 SDK/运行时兼容性 |
| Expo EAS Update | 接入 `expo-updates`，改用 EAS 工作流 | 原生接入、runtime version 与渠道 |
| Pakta | 接入 `rn-update`，登记原生基线并发布 `.ppk` | 原生接入、目标身份与设备恢复 |

Microsoft 原版 [React Native CodePush 仓库](https://github.com/microsoft/react-native-code-push)已经归档，并明确不支持新架构。如果保留 CodePush 客户端，需要逐项核对具体分支和版本。选择 Expo 路径时，遵循 [Expo 官方迁移指南](https://docs.expo.dev/eas-update/codepush/)。

## 改代码前先映射概念 {#mapping}

| CodePush 概念 | Pakta 工作流 | 迁移影响 |
| --- | --- | --- |
| Deployment key | 应用 `appKey` 与原生渠道身份 | 凭据与标识不能直接复用 |
| 目标二进制版本 | 已登记原生包与渠道/版本目标 | 先登记新的准确安装包 |
| 发布 bundle | CLI 生成的 `.ppk` | 从源码重新构建，不上传旧 CodePush 制品 |
| 安装模式与就绪通知 | 更新策略与健康确认 | 重新检查生效时机和启动健康行为 |
| 灰度与回滚 | 目标比例与恢复投放 | 验证设备行为，不能只看控制台状态 |

这是工作流映射，不是 API 兼容声明。实际契约见 [SDK 接入](/docs/integration)与[渠道配置](/docs/channels)。

## 分阶段迁移到 Pakta {#migration}

1. 盘点 React Native 版本、原生模块、Hermes 配置、已安装二进制版本、deployment key 和启动钩子。保留最近稳定版源码与 sourcemap。
2. 在迁移分支中移除 CodePush 的 JavaScript 包装与原生 bundle 加载接入。按 [Pakta 原生配置](/docs/getting-started)或 [Expo 配置](/docs/expo)完成接入，让一个更新系统负责 bundle 选择。
3. 按平台创建 Pakta 应用。配置内部原生渠道，接入根 Provider、生效策略与[健康确认](/docs/integration#health)。
4. 构建并安装新的 Release 二进制，按[首次发布流程](/docs/publish#register-native)登记这份准确的 APK/IPA。
5. 向内部渠道发布一处文案更新。检查更新 hash、冷启动、离线启动和恢复稳定包的行为。
6. 按正常发版流程分发新的原生包。把新包安装覆盖率与旧 CodePush 用户群分开统计，再逐步向新包发布兼容的 Pakta 更新。

## 已安装旧版本的用户怎么办？ {#existing-users}

只包含 CodePush 的 App 需要升级原生包才能包含 `rn-update`。这些设备不能计入 Pakta 可投放范围。为尚未升级的用户保留明确的处理方案，包括其现有安装包实际支持的恢复路径。

取消 Pakta 灰度不会移除已经安装的更新。首次生产投放前先阅读[恢复行为](/docs/channels#lifecycle)。

## 怎样做出选择？ {#next}

保留客户端协议、采用 Expo 更新生态、选择 Pakta 发布工作流，是不同的需求。生产迁移前先用一份 Release 包跑通完整链路。继续阅读 [React Native OTA 基础](/docs/react-native-ota-update)、[Expo Updates 与 Pakta 对比](/docs/expo-updates-vs-pakta)或[快速开始](/docs/introduction)。