核心用法
react-native-update 是 React Native 生态的主流热更新（OTA）解决方案，由中国团队维护，分为 Pushy（国内服务）和 Cresc（全球服务）双线路。
集成路径：
1. 服务选择：根据目标用户地域选择 Pushy（pushy CLI + 国内节点）或 Cresc（cresc CLI + 全球节点），CLI、Dashboard、AppKey 必须同线配套
2. 安装配置：npm install react-native-update，配置 update.json 中的 appKey，原生层注入 Bundle 加载逻辑（iOS RCTPushy.bundleURL() / Android UpdateContext.getBundleUrl() / HarmonyOS 自定义 Provider）
3. JS 层接入：根组件外实例化 Pushy/Cresc 客户端，用 UpdateProvider 包裹应用树，业务代码通过 useUpdate() 获取更新状态（updateInfo、downloadProgress、lastError）
4. 发布流程：release 构建 → 基线包上传 → 热更新包发布 → 客户端 checkUpdate() 触发检测 → 下载 → 应用更新或下次启动生效
显著优点：
- 双服务线路适配国内外网络环境，国内 Pushy 节点延迟低、审核友好
- 支持 React Native CLI、Expo Prebuild、HarmonyOS、Brownfield、Monorepo 等复杂架构
- 提供
canary/metaInfo灰度发布、强制/静默更新策略、版本回滚等生产级功能 - 差分包机制减少下载体积，支持图片等资源热更新
潜在缺点/局限性：
- Debug 限制：热更新仅在 Release 构建生效，Debug 模式只能验证检测/下载逻辑，无法真正应用补丁
- 原生变更壁垒：涉及原生代码、AndroidManifest、Info.plist、Pods/Gradle 配置、原生资源（HAR/AAR/XCFramework）的修改必须重新发版并上传基线
- Expo 冲突：与官方
expo-updates存在 Bundle 加载冲突，需显式禁用或二选一 - 平台覆盖：HarmonyOS 支持相对较新，文档和社区案例少于 iOS/Android
适合人群：
- 需要绕过应用商店审核快速修复线上 JS Bug 的 React Native 团队
- 国内业务优先选择 Pushy，出海业务选择 Cresc
- 已有复杂原生集成（Brownfield）或 Monorepo 架构需精细化配置的团队
常规风险：
- 服务线混用（如
pushy createApp配new Cresc）导致客户端无法检测更新 checkUpdate()误用：其返回值不可靠，必须以useUpdate()的 reactive 状态为唯一数据源- 基线包版本管理混乱导致热更新目标版本错配
- 灰度策略配置不当引发大规模故障时回滚不及时
安全与可信度评估
| 维度 | 评级 | 说明 |
|------|------|------|
| **来源可信度** | T2 | 商业开源产品，国内 React Native 社区广泛采用，GitHub 开源可审计，但非官方 Facebook/Meta 项目 |
| **安全等级** | B | 运行时需下载远程 JS Bundle，存在中间人攻击、篡改风险；建议启用 HTTPS + 签名验证；无涉密数据处理 |
典型场景速查
| 场景 | 关键动作 |
|------|----------|
| Expo 项目 | 使用 Prebuild，注意禁用 `expo-updates` |
| HarmonyOS | 配置 package/provider/bundle-provider 三层 wiring |
| Brownfield | 使用 runtime hook 而非修改 host 继承 |
| Monorepo | 执行 `scripts/integration_doctor.sh` 定位路径问题 |
| 灰度发布 | 配置 `metaInfo` 过滤 + `canary` 流量控制 |