配了三年 React Native，每次发版都要等 App Store 审核——今天新架构把热更新这件事彻底变了

React Native 每次发版都要等 App Store 审核，今天这件事终于有解了——新架构强制化之后，OTA 热更新的方案彻底变了。

背景：为什么要关心 React Native OTA 热更新

做 React Native 的团队，最怕的不是写代码，是等审核。线上发现一个严重 bug，修复完了提交 App Store，等审核要 1-3 天，用户那边已经炸了。传统解法是 CodePush，提前把热更新通道打开，绕过审核直接推。但这个方案从 2025 年开始变得不太好用了。

原因是 React Native 0.82。这是 2025 年 10 月发布的版本，官方把这个版本称为「首个仅运行在新架构下的版本」——也就是说，老架构从这一天起被强制淘汰了。随之而来的连锁反应是：原来那套 OTA 热更新方案，有一部分已经不灵了。

新架构动的是什么

React Native 的新架构主要动的是渲染层和模块加载层。

旧架构： JavaScript 和原生之间靠 Bridge 通信，每次通信要 JSON 序列化，速度慢，还容易卡。渲染靠的是老的 UI Manager。

新架构： JSI（JavaScript Interface）直接替换掉 Bridge，原生模块可以提前加载不用等序列化。渲染换成 Fabric，同步模式让交互响应更快。

问题在于，CodePush 这类工具的底层原理是差量更新 JS Bundle，但新架构下 Bundle 的结构变了，旧的差量算法算出来的补丁装上去会出问题。更直接的原因是：CodePush 官方早就不怎么维护了，社区 fork 出来的方案也缺乏对 Fabric 的适配。

Codemagic Patch：CodePush 的开源接替者

Codemagic 在 2026 年 8 月发布了 Codemagic Patch，这是他们维护了 18 个月的 CodePush fork 的开源版。核心思路是在新架构下重建 OTA 更新链路。

三个关键设计：

CDN-first 分发。 传统 CodePush 直接从自家服务器拉，Patch 把 CDN 节点放在前面，边缘节点就近下载，大幅降低延迟。

Binary Diff 差量更新。 不是每次推送完整包，而是算出当前版本和目标版本的二进制差异，只传差异部分。包体积能减少 70-80%，用户下载更快，也省流量。

Fingerprint 灰度策略。 每个设备有一个指纹，包含 OS 版本、芯片架构、设备型号等信息。可以按指纹分组推送，先推 5% 用户观察 crash 率，没问题再推全量。这是防止热更新翻车的最后一层保护。

新架构迁移检查清单

如果你的项目正在用老架构，或者刚升级到新架构但还没动 OTA 方案，有几件事必须确认：

第一步：确认是否在新架构下运行。 在项目根目录运行 npx react-native info，看输出里是否有 New Architecture: enabled。如果显示 disabled，说明还在老架构下，需要先完成迁移。

第二步：评估现有 OTA 库兼容性。 主流的 react-native-code-push 插件在 GitHub 上已经一年多没有合并新架构相关的 PR 了。如果依赖这个插件，需要找替代方案。Codemagic Patch 是目前社区维护最积极的方案，支持 RN 0.76+ 到最新版本。

第三步：检查 Bundle 产物结构。 新架构下的 JS Bundle 打包产物和旧架构不同，差量更新需要用支持新产物的算法。Patch 的方案是自己在服务端重新算 diff，不依赖旧的 Bundle 结构。

第四步：重新设计更新策略。 旧架构下很多团队用「只要不 crash 就直接推全量」的政策。新架构的模块懒加载机制让冷启动行为和旧架构有差异，建议先走灰度，观察两天再全量。

选型建议

不是所有团队都适合自己维护 OTA 链路。如果团队规模小、App 用户量级在十万以下，直接用 Codemagic Patch 开源版搭一个最简单的 CDN 分发就够了，维护成本低，够用。

如果用户量在百万级以上，建议评估 Codemagic 的商业版或者自己搭一套基于 AWS CloudFront / Cloudflare R2 的分发 + Patch 的方案。核心考虑是 CDN 成本和灰度控制能力，这两个是决定 OTA 稳定性天花板的关键。

选框架的时候，有个判断标准：新架构强制化之后，还有人在持续维护的方案才值得用。一个判断方法——去看 GitHub 上最后一次 commit 时间和 issue 回复速度。

下一步

如果你现在还在老架构上，第一件事是确认 RN 版本和迁移路径。如果已经在新架构但 OTA 方案还是老的，第一件事是搭建一个灰度发布管道，把风险隔离在小范围里。热更新翻车比 App Store 审核慢的破坏力大得多——审核慢只是等，热更新翻车是直接把用户炸了。