从 Expo 快速起步到原生可控的工程化路径

前言

很多团队担心“用 Expo 会不会被绑死”。事实上,Expo 更像一条渐进式路线:你可以先用它快速交付,再逐步解锁原生能力。关键是理解每个阶段的边界与切换成本。

本文给出一条实用的工程化路径,帮助你在不牺牲速度的前提下,获得更高的可控性。

阶段 1:快速起步(Managed)

目标是“低成本验证业务”:

• 使用 expo init 创建项目
• 统一在 app.json/app.config 中配置原生参数
• 直接使用 Expo SDK 提供的能力
• 用 Expo Go 或 Web 进行快速调试

这一阶段的优势是上手快、配置少、团队协作成本低。适合 MVP 和早期验证。

阶段 2:Dev Client 解锁自定义能力

当你需要一些 Expo Go 不支持的能力时,可以引入 Dev Client:

• 支持自定义 native modules
• 仍可使用 Expo 工具链和调试体验
• 与后续 Prebuild 兼容

这一步的意义在于“把原生能力引入项目,但不放弃 Expo 的工程化体系”。

阶段 3:Prebuild 生成原生工程

当需求更复杂时,可以通过 expo prebuild 生成 iOS/Android 工程:

expo prebuild

生成后的原生工程可以直接修改,但仍然保留 Expo 的配置与脚本能力。这是 Expo 进入“可控原生”的关键点。

阶段 4:Config Plugins 管理原生变更

为了避免“手改原生工程”带来的不可维护,Expo 提供 config plugins 来把原生配置变成可复用脚本:

• 让原生改动可版本化
• 支持多环境配置
• 在团队协作时减少冲突

如果你的项目依赖多个原生模块,这一点非常关键。

阶段 5:EAS Build/Update 工程化落地

最终的交付体系通常会落在 EAS 上:

• EAS Build:统一构建 iOS/Android
• EAS Submit:自动提交商店
• EAS Update:OTA 更新,快速修复线上问题

这能让前端团队在没有专职移动端 DevOps 的情况下,也能拥有可控的发布流程。

一个渐进式示例流程

你可以按以下节奏推进:

1. Expo Managed + Expo Go → 业务验证
2. 引入 Dev Client → 接入自定义原生能力
3. Prebuild → 生成原生工程
4. Config Plugins → 原生改动工程化
5. EAS Build/Update → 交付闭环

每一步都是“可逆”的,不会强迫你一次性投入太多成本。

结语

Expo 的价值不在于“替代原生”,而在于提供一条更平滑的工程化路径。对大多数前端团队而言,从 Expo 起步,再逐步解锁原生能力,是性价比最高、风险最低的路线。