React Native 与 Expo 的关系与定位

前言

很多前端同学第一次接触移动端开发时都会问:React Native 和 Expo 到底是什么关系?是不是二选一?要回答这个问题,最好的方法是把它们放到同一个技术分层里看。

一句话概括:React Native 是跨平台渲染与运行时,Expo 是围绕 React Native 构建的一整套开发与发布平台。前者解决“如何渲染与运行”,后者解决“如何更快、更稳地开发、构建、发布”。

React Native 是基础层

React Native 本质上是一个跨平台运行时和 UI 渲染框架:

• 运行时:JS 引擎 + Bridge/新架构(JSC/Hermes/JSI)
• UI:用 React 语法描述组件,渲染到原生 UI
• 生态:大量原生模块与三方组件

它负责把你的 JS/TS 代码变成 iOS/Android 上的原生体验,但不负责“如何初始化项目、如何打包、如何分发、如何做配置管理”。这些工作要么靠 CLI 工具,要么靠你自己搭建工程体系。

Expo 是生产力层

Expo 的定位更像“React Native 的平台化工具链”,它提供:

• 项目脚手架与统一配置(无需手动 Xcode/Android Studio)
• 内置常用原生能力(相机、定位、通知、文件等)
• 统一的构建与发布服务(EAS Build/Submit/Update)
• Dev Client 与本地开发调试

你可以理解为 Expo 在 React Native 上封装了一层“工程化最佳实践”。不改变 RN 的核心渲染与运行方式,但让整体体验更可控、更标准。

两者的关系:不是替代而是层级

常见误区是把它们当成对立选项。更准确的理解是:

• React Native 是底座
• Expo 是围绕底座的工具与服务

因此“用 Expo 写 RN”是自然且常见的方式。它不改变 RN 的技术本质,只是把项目初始化、构建、配置、发布等工作抽象掉。

Expo 的两种形态

Expo 并不是单一模式,它覆盖两条路径:

1) Managed Workflow (托管模式)

开发者只写 JS/TS,通过 app.json/app.config 描述原生配置。绝大多数常见能力直接调用 Expo SDK,无需写原生代码。

适合:快速验证、MVP、团队原生经验不足的项目。

2) Bare/Prebuild (原生可控)

通过 expo prebuild 生成原生工程,依旧可以享受 Expo 的工具链(EAS Build/Update),但允许接入自定义原生模块。

适合:需要深度原生能力、复杂依赖或性能优化的项目。

Expo 的边界与现实限制

使用 Expo 也不是“万能”的,要理解它的边界:

• SDK 更新节奏可能影响三方库兼容
• 少数原生能力需要自己写 module 或 config plugin
• 对某些高度定制化的原生需求,还是要回到原生工程

但值得注意的是,这些限制更多是“选择成本”而不是“技术天花板”。随着 Dev Client 与 config plugins 的成熟,Expo 已经能覆盖多数中大型项目的需求。

如何判断是否用 Expo

可以用一句话做判断:

• 如果你的核心目标是“快速交付 + 稳定工程化”,优先选择 Expo
• 如果你的核心目标是“极致原生能力 + 高度定制”,考虑 CLI 或 Bare 模式

大多数团队其实可以从 Expo 起步,在确实需要时再解锁原生工程,而不是一开始就走最重的路径。

结语

React Native 负责“跨平台运行与渲染”,Expo 负责“让 RN 项目更容易做对”。理解它们的层级关系,你就不会被“该不该用 Expo”困住,而是能够根据项目阶段与团队能力做出更理性的选择。