企业官网建设流程全解析

有段时间，我跟一个做企业移动应用的朋友聊天，他抛出一个很具体的痛点：他们的 App 是 Expo 开发的，上线后遇到一个不算致命但很影响体验的 bug。走应用商店审核太慢，于是他们想用 OTA 更新，把修复后的 JS bundle 直接推到用户设备上。单看这个动作，流程很简单，几分钟就能搞定。但真正麻烦的问题在发布之后：更新包存在哪里、由谁控制、用户升级失败了怎么办、线上这么多设备到底各自跑在哪个版本、服务端有没有人盯着。这个场景里，“自托管 OTA 更新 + 可观测性”这套组合，才有了不可替代的位置。

Xprem 这个项目的标题，刚好踩在两个关键词上：Self-hosted OTA updates 和 observability for Expo apps。它要解决的不是“把官方托管服务换到自己服务器上”这种表面迁移，而是让发版、升级、回滚、观测整条链路真正回到团队自己的控制面里。

我的主判断很简单：这类自托管方案，核心价值不在“省了一次上传下载”，而在把发布过程和运行过程变成可审计、可干预、可观测的数据。如果只是把 bundle 文件放到自己的服务器，却不解决版本匹配、失败回滚、日志追踪，那和网盘分享没有本质区别。

1. 先搞清楚 Expo OTA 更新到底是怎么工作的

1.1 一次 OTA 更新的完整链路

Expo 应用的 OTA 更新，不是简单地把新代码“推”给用户，而是有一套请求、校验、下载、缓存、加载的流程。

以常见的expo-updates工作方式为例，App 启动时会向配置好的更新服务端发起请求，获取一个更新清单，也就是 manifest。服务端根据 App 的请求参数返回对应的清单，里面记录了当前应该加载哪个 bundle、依赖哪些 assets、更新资源应该从哪里下载。客户端拿到清单后，会检查一个非常关键的字段——runtimeVersion。如果清单里的 runtimeVersion 和当前原生包一致，就继续下载并缓存新资源；如果不一致，就认为这次更新不适用于当前设备，继续使用内置的 bundle。

这个机制决定了 OTA 更新能成功的边界：它只能更新 JavaScript 代码、图片、字体这类资源，不能更新原生模块。一旦原生代码发生变化，比如新增了 SDK、改了原生权限，就必须重新构建并发布新的原生版本。

理解这个链路之后，再看自托管方案，就不会把它误解为“搭一个静态文件服务器”。

1.2 为什么这个问题过去不好解决

在 Expo 生态里，EAS Update 是官方托管方案，体验确实很顺。项目里配置好之后，运行一条命令就能发布更新，后台还能看到基本的版本记录。对于大多数团队，这个方案完全够用。

但有一类团队会卡住。比如做政企项目、金融内部系统、数据合规要求严格的团队，他们不允许应用运行数据、用户设备信息、更新记录落到外部第三方服务。还有一些团队的网络环境本身就是私有化的，外部请求根本出不去。这时候，托管方案再方便也无法使用。

过去自托管的问题在于：你需要自己实现服务端，兼容 Expo 的更新协议，处理 manifest 生成、asset 托管、版本匹配、客户端上报。这些工作零散，单独做没有任何优势。所以很长一段时间，大家宁可忍受托管服务的边界，也不愿意自己造一套轮子。

Xprem 这类项目出现，就是把过去散落的服务端能力打包起来，让自托管变成一条可以走的路径。

1.3 自托管之后，控制权具体多在哪里

很多开发者对“自托管”的理解是：我可以自己控制服务器，出了问题能看日志。这没错，但太浅了。

真正多出来的控制权，至少有三块：

• 数据边界：更新包、设备上报、用户事件都保存在自有基础设施里，网络策略、文件权限、加密方式、日志保留时间都由自己定义。
• 发布流程：可以按自己的节奏设计发布审批、灰度比例、失败熔断、操作审计，而不是依赖第三方后台提供什么功能。
• 观测链路：可以把自己关心的指标接到现有的监控告警体系里，比如 Prometheus、Grafana 或者自研的可视化平台，而不是在第三方后台里看一个隔离的数据面板。

这三块控制权，才是“Self-hosted”四个字的真实含义。

2. Xprem 这类项目真正在做的事：把更新和观测放进同一条链路

2.1 更新分发：服务端要支撑的不只是下载

单从功能看，自托管 OTA 服务端需要做的事情非常具体：

• 接收开发者的更新包上传，可能是一个 manifest 加一个 bundle 文件，再加上若干 assets。
• 把更新资源转存到服务端自己的存储空间，比如本地磁盘或对象存储。
• 对外提供更新清单查询接口和资源下载接口，客户端启动时从这里拉取。
• 根据渠道或者平台，决定把哪个更新返回给请求的客户端。

如果只做这四件事，它确实就是一个上传下载工具。但真实生产环境里，服务端还要处理更多问题：

• 多个版本同时在线时，怎么选择返回哪个 manifest。
• 上传的是损坏包，或者 manifest 里记录的 asset 缺失，怎么拦截。
• 客户端并发请求很高时，带宽、CPU、磁盘 IO 是否扛得住。
• 存储不停增长之后，旧版本资源什么时候清理、保留多久。

这些都不是“跑通一次发布”能覆盖的问题，而是长期维护要面对的问题。Xprem 把服务端能力统一收拢，意味着团队不需要再自己拼装这些模块。

2.2 可观测性：从“你发了吗”到“发出去之后发生了什么”

做过线上发版的人都懂一件事：发布动作只是开始，真正让人焦虑的是发布之后无法确认结果。

托管方案通常能告诉你“这个版本什么时候被发布”，但回答不了这些问题：

• 有多少设备实际请求到了这个更新。
• 多少设备下载成功并加载了新的 bundle。
• 多少设备请求之后没有任何后续动作，可能卡在下载或校验环节。
• 新版本上线之后，报错率是升高了还是降低了。
• 当前线上有多少比例的设备还停留在旧版本。

自托管的可观测性，就是要回答“发出去之后发生了什么”。它会记录客户端请求、下载成功、加载成功、运行报错之类的状态事件，把这些事件归拢成可以看到的指标和日志。这样团队才有能力判断一次发布是成功还是失败。

这听起来像“加个日志功能”，但实际上，它把发布动作从单向的“推”变成了带反馈的“发布—验证—决策”闭环。没有这个闭环，OTA 更新就是盲发。

2.3 一条链路三个角色：服务端、客户端 SDK 和配置面

要把更新和观测闭环起来，Xprem 这类项目通常会包含三个组成部分。

• 服务端：负责承接更新上传、manifest 分发、状态事件接收、数据查询和展示。
• 客户端 SDK 或配置插件：负责让 Expo 项目知道去哪里找更新服务，并把启动、下载、加载、报错等状态上报回去。
• 配置面：把项目、渠道、runtimeVersion、发布策略这些信息管理起来，让服务端知道“哪一个 App 的哪一类设备应该拿哪个更新”。

三个角色缺一个，闭环就不完整。没有客户端上报，服务端只能被动等下载请求，看不到设备端结果；没有配置面，每次发布都得手工处理版本关系，迟早出错。

从使用者的角度看，接入 Xprem，本质上不是接入一个“上传文件的工具”，而是接入一套「发行控制台 + 运行观测台」。

3. 从零接入的一条可复用路径

3.1 先跑通最小闭环

不论你最终要部署多大规模，第一步永远是：用最小的资源把一条更新链路跑通。不要一上来就规划高可用集群、多机房 storage、复杂权限系统。

先准备一套最基础的运行环境：

• 一台服务器或一个容器环境，规格不需要太高，能跑起服务端进程即可。
• 一个域名和对应的 HTTPS 证书。这一步尽量提前准备好，因为移动端生产环境对证书要求比较严格，后面会单独说。
• 一个存储目录，用于保存上传的更新资源，后续可以换成对象存储。

部署方式要看项目文档提供什么。如果支持 Docker Compose，通常是最快的路径；如果只提供源码部署，就要先确认 Node 或运行时版本。原始材料没有给出的环境依赖，落地前先翻文档确认，不要凭经验猜。

启动服务端之后，第一件事不是接客户端，而是先通过管理端或用 API 创建一个应用记录，拿到这个应用对应的标识和访问凭证。这些凭证后面要写进客户端配置里。

3.2 客户端需要改什么

Expo 项目接入自托管 OTA，关键改动在配置文件和应用设置里。

首先，项目里要安装并配置expo-updates。如果用的是 development build，通常可以直接通过npx expo install expo-updates安装，并确保配置文件里启用了 updates 相关设置。

其次，在app.config或app.json里，把更新服务地址指向自托管服务端。常见配置大概是updates.url指向你部署的服务地址，同时设置runtimeVersion或对应的策略。这一步是接入的核心，URL 写错或者 runtimeVersion 不匹配，后面全都白做。

最后，需要重新构建原生应用。expo-updates是原生模块，不是纯 JS 库，只更新 JS bundle 不能让它生效。也就是说，第一次接自托管方案时，你需要出一个包含新配置的测试包，装到测试机上验证，而不是只跑expo start。

这一步很容易被忽略，很多人改完配置，运行开发服务器发现能连上，就觉得成功了。实际上开发模式和打包后的生产模式行为不完全一样，一定要用真正的构建产物验证。

3.3 发布一个更新并验证

客户端准备好之后，可以走一次完整的更新发布流程。

常见的链路是这样：

• 用 Expo 导出命令生成更新产物，例如npx expo export，把 JS bundle 和 assets 输出到指定目录。具体命令和参数以当前 Expo SDK 的文档为准。
• 把导出的目录上传到自托管服务端，关联到对应的应用和渠道。
• 在服务端确认 manifest 生成无误，资源文件完整。
• 用内部测试设备启动 App，观察是否请求到新版本，是否能正常加载。

第一波发布，不要直接全量。先把更新推向测试渠道或内部设备渠道，确认没有严重报错之后，再走正式渠道。

这个阶段的目标不是“发布一个完美的版本”，而是确认整条链路没有断点：服务端能收、客户端能拉、拉完能跑、跑完能上报。只要这条链路是通的，后续的发布都能复用同一套流程。

3.4 观察数据：更新是否真的生效

发布之后，不要只看“发布成功了”这个状态。去服务端的观测界面或数据接口里看几个关键信号：

• 服务端有没有收到测试设备的更新请求。
• 请求的设备数量和测试设备数量是否对得上。
• 有没有完成下载并加载新 bundle 的状态记录。
• 有没有报错记录，比如下载失败、校验失败、manifest 解析失败。

如果请求都没收到，先查客户端配置的 URL 是否可达，证书有没有问题；如果收到了请求但下载失败，检查文件是否完整、存储权限是否正常；如果加载之后报错，那就要回到业务代码本身排查。

这其实就是后面要展开的排查链路的第一轮实践。把它养成习惯，比再研究任何高级功能都重要。

4. 决定成败的四个关键细节

4.1 runtimeVersion：为什么它比 app 版本号更值得关注

社区里很多“发了 OTA 但用户没反应”的问题，最终都指向 runtimeVersion 不匹配。

App 版本号是给用户看的，用来表达业务迭代；runtimeVersion 是给更新系统看的，用来描述“当前原生运行环境是否兼容这个 JS bundle”。如果原生包里有某个原生库升级了，对应的 runtimeVersion 就应该变化。否则，旧的原生包会尝试加载一个依赖新原生能力的 bundle，运行期可能报错甚至白屏。

Expo 生态里，runtimeVersion 可以手动指定，也可以设置策略。比如按 app 版本号自动对齐，或者用 fingerprint 策略，根据原生构建的指纹信息生成更精确的版本标识。不同策略各有取舍：

• 手动指定最可控，但需要团队维护规则，容易忘改。
• 跟随 app 版本，简单直接，粒度比较粗。
• fingerprint 更精确，能自动感知原生依赖变化，但可能造成更新过于频繁，每次原生配置变化都会生成新版本。

实际落地时，至少要做到：每次原生构建产物变化，都要重新确认 runtimeVersion 是否需要更新。否则你发出去的不是补丁，而是一颗定时炸弹。

4.2 HTTPS、证书和运营商网络

移动端生产环境访问更新服务，常规要求是 HTTPS，这不是可选配置。

原因很直接：更新包本质上是可执行代码。如果请求被中间人篡改，客户端可能加载到被替换过的 bundle，后果非常严重。自签名证书在测试环境勉强能用，但在生产环境不可行，而且 Android 和 iOS 对证书信任策略差异明显。

部署时应该用一个正规渠道签发的证书，并且确保证书链完整。常见坑点包括：

• 使用多级证书时，服务端没有配中间证书，导致部分设备验证失败。
• 证书过期后没有及时更新，用户升级时突然失败。
• CDN 或网关层证书和源站证书不一致，出现区域性请求异常。
• 某些国家和地区运营商网络会缓存或拦截不常见的请求，导致更新包下载不完整。

这些问题的共同特点是：开发环境很难复现，只有线上设备会出问题。所以一旦上线，证书有效期、证书链完整性、CDN 回源配置，都要纳入定期检查范围。

4.3 回滚不是一个操作，而是一个预案

很多人觉得回滚很简单：把上一个版本再发布一次不就行了。

这个理解忽略了 OTA 更新的时序问题。客户端不是每次打开都会更新，很多设备会缓存已经下载过的 bundle。当你发现线上版本有问题时，一部分设备可能已经加载了新版本，一部分还在用旧版本，还有一部分正处于下载中。这种情况下，“再发一次旧版本”并不能立刻把已经加载新版本的设备拉回来。

好的回滚预案至少要考虑这几层：

• 能不能在服务端暂停某个更新的对外分发。
• 已经下载但还没加载新版本的设备，能不能阻止它们继续加载。
• 已经加载了新版本但出现报错的设备，客户端里有没有兜底逻辑，比如启动失败后回退到上一个可用 bundle。
• 每次发布和回滚操作，有没有审计日志，用来追溯是谁在什么时间做了操作。

自托管方案的一个优势，就是回滚逻辑可以做到更深。你可以根据自己的业务定义更严格的回滚策略，而不是依赖托管平台给什么就用什么。

4.4 存储、备份、日志保留和磁盘清理

自托管绕不开运维。服务器不是上传完就完事了。

更新包和 assets 会持续占用存储空间。项目迭代多了之后，版本数量会快速增长。如果只增加不清理，磁盘迟早写满，到时候发布新版本都会失败。

建议至少做三件事：

• 设置更新资源保留策略，比如保留最近 N 个版本或最近 M 天，更早的版本如果不需要回滚就可以归档或删除。
• 定期备份，重点不是备份 bundle 文件，而是备份更新元数据。没有元数据，文件本身也很难被有效管理。
• 对磁盘使用量、对象存储用量、日志增长量设置监控。清理动作最好做成周期任务，而不是等告警才处理。

这些工作不复杂，但很重要。因为它们决定系统能不能长期稳定运行，而不是在演示时表现完美。

5. 可观测性数据怎么用起来

5.1 建议优先看的五个指标

可观测性功能如果集成了一堆指标，反而不好落地。我建议从五个指标开始看，每个指标都对应一类明确的异常：

这五个指标覆盖了发布链路的三个关键节点：能不能拉到更新、能不能装上更新、装上之后稳不稳定。

5.2 从异常现象反推问题的排查顺序

可观测性不只是看图表，它更重要的作用是帮你在异常出现时快速定位问题。建议按下面的顺序排查：

1. 先看现象：是用户没有收到更新，还是收到更新但加载失败，还是加载之后报错。
2. 再看更新请求：服务端有没有收到该设备和版本的请求。没有请求，优先检查客户端配置、URL 可达性、证书。
3. 再看 manifest 返回：如果请求到达但返回不匹配，检查渠道、平台、runtimeVersion 配置。
4. 再看下载：如果 manifest 正常但下载中断，检查资源文件是否完整、存储权限、网络链路。
5. 再看加载：如果下载成功但加载异常，检查 bundle 本身有没有问题、原生环境是否匹配。
6. 最后看上报：如果设备行为无法解释，增加客户端日志，确认上报链路本身没有丢数据。

这套顺序不复杂，但它能避免一个最常见的问题：一上来就怀疑代码，结果折腾半天发现是证书过期。

5.3 告警不是越多越好

自托管系统的可观测性，很容易做成“把所有指标都加个告警”。结果就是告警轰炸，真正出问题时没人看。

更务实的做法是，前期只对少数几个信号设置告警：

• 更新请求数出现明显下跌或归零。
• 下载成功率连续超过阈值，比如低于 95%。
• 某个更新版本的报错率显著高于基线。
• 磁盘使用率或存储量超过安全线。
• 出现回滚操作时，通知到负责发布的人。

先让这五条告警正常工作，再根据实际运营情况逐步增加。告警的价值不是“把数据都变成通知”，而是“在异常真正影响用户之前，让合适的人知道”。

6. 自托管方案的真实边界和选型判断

6.1 哪些团队适合这条路，哪些不适合

自托管不是所有人都该走的路。它带来的自由，同时意味着你也接过了运维责任。

适合自托管的团队，通常有几个特征：

• 有数据边界或合规要求，更新和观测数据不能离开自己的基础设施。
• 应用部署在私有化网络环境里，外部服务不可用。
• 团队有基本的服务端运维能力，能处理部署、证书、存储、备份这些日常任务。
• 发布流程需要深度定制，比如特殊的审批流、灰度策略、审计要求。

不适合自托管的团队，特征也很明显：

• 团队只有前端经验，完全没有服务端运维基础。
• 项目规模小，更新频率低，设备的更新数据没有合规要求。
• 追求开箱即用，不希望在基础设施维护上花时间。

这两种选择没有高下之分。托管方案的价值在于省心，自托管的价值在于可控。把需求理清楚，选择反而简单。

6.2 和 EAS Update 的取舍不要只看价格

评估自托管方案时，最容易犯的错是只算服务器成本，然后得出“自托管更便宜”的结论。

真正的成本结构要复杂得多。托管方案的成本优势不在服务器，而在减少了你对发布、监控、证书、存储、安全、备份整套系统的维护投入。自托管的成本也不在服务器，而在那些看起来不起眼的日常任务：证书更新、磁盘清理、日志排查、安全补丁。

更合理的判断维度是：

• 你更在意数据自主，还是更在意团队投入产出比。
• 你的发布频率高不高。如果每周多次发布，自托管带来的控制力会显著；如果一个月才发一次，托管方案并不吃亏。
• 你的设备量和用户量有没有特殊的规模化问题。自托管方案在数据量增长后，性能和稳定性工作是由自己承担的。
• 团队能不能在事故发生时，有能力和意愿去排查服务端问题。

如果这些问题没有清晰的答案，不要为了“开源”或“免费”贸然切换。

6.3 如果决定接入，第一周该做什么

如果你决定在自己的项目里接入自托管 OTA 更新和可观测性，我的建议是：第一周不要直接规划生产环境，先做四件事。

1. 搭一套最小环境，只跑通服务端和客户端之间的更新链路。
2. 用测试设备完成一次“推送更新—确认生效”的完整验证。
3. 把前面说的五个关键指标和一条排查链路整理成文档，发给团队成员。
4. 写一份回滚演练方案，并在测试环境真实演练一次。

这四件事做完，你才算真正理解了这套方案在你项目里的表现。之后再考虑生产部署、渠道划分、灰度策略、告警接入和对象存储迁移，顺序才合理。

最后想说的话

回到开头那个朋友的问题。他真正需要的，不是一个“把更新包放到自己服务器”的工具，而是一个能回答“我的用户现在跑在哪个版本、升级是否顺利、出了问题能不能马上回滚”的控制面。

Xprem 这类项目的价值，就是把这个控制面还给团队自己。自托管意味着责任也一起回来了。如果你准备走这条路，第一课不是学会发布，而是先学会定义：什么时候算成功，什么时候必须回滚，以及从哪里能最快看到异常。

这三件事想清楚，工具层面的问题都不会太复杂。