作者：Jacob Clausen
本文将为你详解如何通过分阶段发布、实时监控和回滚策略，在生产环境中安全落地 Expo OTA 热更新（EAS Update），让你能满怀信心地向用户推送更新。
Expo 提供的 OTA 热更新服务（EAS Update）能在短短几分钟内将更新推送给用户，这一特性十分便捷。但有时，慢一点推进反而更稳妥，尤其是当你需要观察更新在真实生产环境中的表现时。
真实用户、真实设备、真实流量，才能反馈最真实的产品使用信号。EAS Update 既支持快速的更新分发，又能让你对生产环境的更新推送节奏、用户反馈数据的收集环节实现精准把控。
对更新的测试时间越久、覆盖场景越全面，推送就越安全。但生产环境往往不会给你无限的测试时间，过度放缓更新节奏也会产生实际的业务成本。EAS Update 并非要消除这种权衡，而是通过让你掌控更新的触达范围、推送时机和故障恢复方式，为每一次更新选择最适合的推进节奏。
本文将带你梳理 EAS Update 在生产环境的完整落地流程，从分阶段发布、实时监控，到更新终止与回滚，重点讲解这些机制在真实生产环境中的实际表现。
Expo 官方文档中介绍了多种团队常用的 EAS Update 部署模式 —— 从直接发布到生产环境的两步简单命令流，到包含预发布渠道和版本化分支、支持发布前结构化测试的复杂流程。
你选择的具体部署模式，会决定更新的构建和验证方式，但本文中提到的运营原则（逐步推送更新、观察真实反馈、根据数据及时响应），无论采用哪种工作流，在更新进入生产环境后均适用。
刻意小范围推送更新
在生产环境中，小范围推送更新通常意味着限制更新的触达范围。
不必让更新立即对所有用户开放，你可以先向小比例用户推送，以此控制影响范围，并有机会在进一步扩大推送前，观察更新在真实场景中的表现。
分阶段发布会限制应用检查更新时，可接收该更新的用户比例，其余用户则继续使用上一个版本的更新。
本文中的示例均基于单更新分阶段发布，即针对单次发布的更新进行范围控制。
例如，你可以发布一个更新并设置初始推送比例：
eas update --rollout-percentage=10
这一操作能同时控制成本和更新影响范围，还能为你争取时间，观察更新在生产环境中真实用户的使用情况。
EAS Update 还支持基于分支的分阶段发布，该模式会逐步将用户切换至另一个更新分支（一个持续的更新流）。如果你想了解这两种发布模式在实际使用中的差异，可参考部署指南中对各类发布模式的简短说明。
当你准备评估更新的实际表现时，下一步需要明确关注哪些数据信号，以及如何解读这些信号。
关于更新包大小与带宽的说明
用户下载的每一次更新都会消耗带宽。例如，若你每周发布一次更新，而用户会定期打开应用，那么一个月内用户可能会下载多次更新。
EAS Update 提供了充足的带宽配额，因此对于大多数应用来说，正常使用中不会出现带宽不足的问题。减小更新包大小，主要是为了提升更新的可靠性，并让你有更多空间实现高频次的更新推送。
随着 Expo SDK 55 的发布，你可以选择启用Hermes 字节码差分更新（目前处于测试阶段）。该功能会将更新以二进制补丁的形式分发，而非完整的 JavaScript 包。客户端无需下载全新的字节码文件，只需在已安装的文件基础上应用差分补丁，既能减小下载体积，也能降低带宽消耗。
字节码差分更新大幅提升了可用带宽的余量，让用户能下载更多更新，同时消耗更少的流量。
监控生产环境的分阶段发布
当更新向小比例用户推送后，你可以通过 EAS 控制台，近乎实时地查看更新在生产环境中的表现。
更新的采用率与推送量
首先需要关注的指标，是实际接收并应用更新的用户数量。
例如，设置 10% 的推送比例，并不代表 10% 的用户会立即应用该更新。默认情况下，应用会在冷启动时检查更新，若有可用更新则进行下载，且更新会在应用下次重启时生效，这意味着用户不会同时完成更新的应用。
有些开发团队会将fallbackToCacheTimeout参数微调几秒，让应用在启动时短暂等待更新下载完成，从而实现更新的即时生效。这一操作能提升更新采用率，但也会影响应用启动体验 —— 因为更新下载时，启动页可能会持续显示。
更常见的做法是，团队通过更新相关的 JS API 观察并响应更新的生命周期。useUpdates这类 Hook 能暴露更新系统的状态（例如应用是否正在检查更新、是否有可用更新、是否已完成更新下载），让你能在应用渲染完成后，协调控制更新的应用时机。
无论采用何种配置，分阶段发布过程中，你通常期望看到的是更新采用率随时间逐步提升，而非瞬间的激增。
如果采用率异常偏低，这本身就是一个重要信号：可能是用户打开应用的频率不足以触发更新检查，也可能是该更新并非你预期的构建版本所能接收 —— 例如，更新的目标运行时版本，与这些构建版本支持的版本不匹配。
崩溃与致命错误
在分阶段发布的初期，崩溃数据往往是最直观的反馈信号。启动崩溃和运行时致命错误会快速暴露，因为受影响的用户在运行更新后会立即遇到这类问题。
你通常会首先在 Expo 控制台的部署和更新视图中发现这类问题，在该视图中，你能看到每个更新的启动数据，以及对应的崩溃次数。
要排查更新崩溃的原因，通常需要结合第三方崩溃监控工具，例如集成 Sentry，让堆栈跟踪信息和会话上下文能与部署数据联动查看。Sentry 能捕获大多数运行时崩溃和异常，但极早期的启动崩溃，可能仍只能通过平台级崩溃报告查看，例如 App Store Connect 或 Google Play 控制台的报告。
EAS Update 还内置了错误恢复机制：如果新应用的更新在启动极早期（应用成功渲染任何内容之前）发生崩溃，应用会将该更新标记为失败，并回退到上一个可正常运行的更新版本。这一防御机制的设计目的，是防止应用陷入无法使用的状态 —— 即启动即崩溃，且运行时间短到无法下载修复更新。
关注数据趋势
分阶段发布初期的数据往往存在噪音，小样本量会放大数据的波动，尤其是当只有小比例用户接收更新时。
切勿针对单个数据点做出反应，而是要关注数据趋势，例如：
- 随着接收更新的用户增多，崩溃率或错误率是否发生变化？
- 崩溃是否集中在更新发布后的时间段？
利用这些信号判断，扩大更新触达范围是否会改变你观察到的表现。如果随着用户采用率提升，崩溃率和错误率仍保持在可接受范围，那么通常可以合理地扩大推送范围；如果这些指标随采用率增长而恶化，则应暂停扩大推送。
安全扩大更新的推送范围
当更新在有限范围内稳定运行后，下一步需要决定是否向更多用户推送。
扩大推送范围不会改变更新本身，你无需发布新的更新包，只是让更多设备在下次检查更新时，具备接收该更新的资格。
例如，要提高更新的推送比例，可执行以下命令：
eas update:edit
执行后会出现交互式引导，带你完成更新的选择和新推送比例的设置。
如果监控的各项信号在触达范围扩大后，仍保持在可接受水平，你可以继续扩大推送范围，直到更新对所有用户开放。
更新回滚策略
如果分阶段发布过程中出现问题，你可以根据更新的推进程度，通过两种方式终止或撤销更新。
若更新仍在分阶段发布中，你可以撤销该次发布；若更新已对所有用户开放，则需要执行版本回滚操作。
撤销正在进行的分阶段发布
当更新还在分阶段推送时，你可以撤销此次发布。撤销操作会终止当前的分阶段发布，并重新发布上一个稳定版本的更新，让所有客户端恢复到之前的状态 —— 包括已经接收并应用了该更新的用户。
当数据信号表明更新不应继续推送，且你希望在其触达所有用户前消除影响时，撤销发布是最佳选择。
要撤销正在进行的分阶段发布，执行以下命令：
eas update:revert-update-rollout
分阶段发布完成后的回滚
当分阶段发布完成后（例如推送比例达到 100%），已无发布可撤销。此时若判定该更新不应继续运行，则需要执行回滚操作。
回滚会发布一个新的更新指令，指示客户端运行上一个稳定版本，或回退到应用打包时内置的原始更新版本。
回滚操作适用于更新已完全推送给所有用户，且你需要将用户恢复到已知稳定状态的场景。
要回滚到上一个更新版本，执行以下命令：
eas update:rollback
执行后会出现交互式引导，协助你选择回滚类型并完成回滚操作。
关于持久化状态兼容性的说明
撤销分阶段发布或回滚到上一个更新版本，有一个前提：旧版本的代码，能与新版本更新创建的所有持久化状态兼容。
如果某次更新引入了非向后兼容的变更（例如修改了本地存储或数据库的架构），将用户回退到旧版本更新，可能会导致应用崩溃或出现异常行为。
在无法安全回滚的情况下，你可能需要发布一个恢复兼容性的新更新。
排查更新相关问题
Expo 官方文档中包含一份详尽的调试指南，梳理了常见的更新失败场景，例如：构建版本无法接收更新、运行时版本不匹配、更新后应用立即崩溃、资源加载失败等。指南还介绍了实用的调试策略，例如查看expo-updates日志、验证运行时版本、检查更新清单等。
大多数更新问题的根源，都是配置不匹配或构建版本不符合更新的接收条件，一旦找到排查方向，这些问题通常都能轻松诊断。
总结
如果你还未在生产环境中使用 EAS Update，十分值得一试。直接向用户推送热更新，起初可能会让人觉得是一大步，但借助分阶段发布、实时监控和故障恢复方案，你能满怀信心地推出更新。
EAS Update 让你既能快速迭代，又能全程掌控：你可以逐步推出变更，观察其在真实用户中的表现，并在需要时及时响应 —— 所有操作都能在同一工作流中完成。
EAS Update 提供了极佳的开发者体验，让开发团队能专注于快速打造世界级的用户体验和产品优化。
养成良好的运营习惯后，OTA 热更新会成为一种自然、可靠的方式，助力你为每日使用应用的用户持续优化产品体验
