2. 工作流选择与环境配置

在 Expo 体系中，工作流的抉择直接决定了你的工程复杂度、研发效率与可维护性。本章从“为什么这样选”到“怎么落地”的视角，系统梳理 Managed、Dev Build 与 Bare 三种模式的边界与组合打法，并提供适用于团队协作与生产环境的环境配置范式、标准脚手架与问题排查清单。阅读完本章，你应能在项目伊始就做出稳健选择，并在生命周期内平滑演进而不被技术债拖累。

一、工作流选型：Managed、Dev Build 与 Bare 的真正边界

• Managed（托管工作流）：

• 核心价值：把“原生工程的繁琐与脆弱”交由 Expo 代管，开发者聚焦 JS/TS 业务。绝大多数官方 SDK 模块即插即用。

• 能力上限：借助 Config Plugins 可修改 Info.plist、AndroidManifest、Gradle 配置，解决权限、依赖与初始化等原生层配置问题。结合 Dev Build，可在托管模式下调试并运行包含自定义原生依赖的客户端。

• 典型适配：中小团队、追求快速验证与高频迭代的业务线、以 JS 层为主的产品。

• Dev Build（开发构建）：

• 是什么：在 Managed 模式下生成“包含你所需原生依赖”的专用调试 App，替代 Expo Go 的能力边界。

• 核心作用：让你在不 ejection 的前提下，使用第三方原生库或自研模块进行真机调试。

• 何时需要：当某个模块不在 Expo Go 内置集合中时（如 IAP、部分蓝牙库），或需要修改原生配置。

• Bare（裸工作流）：

  • 核心价值：完全掌控 ios/ 与 android/，可深度自定义编译链、与既有原生仓库合并、使用任意原生库。
  • 代价：你需要维护原生依赖、CI、证书、构建脚本与升级路径；升级成本高，对经验要求更强。
  • 适配：强原生诉求（自研 SDK/厂商深度集成/特定 ABI 或编译器版本要求）、已有原生团队与基础设施。 最佳实践：先选 Managed，配合 Config Plugins 与 Dev Build 解决 80–90% 的需求；仅在确认必须深度原生改造时转 Bare。这样能延迟复杂度、降低维护成本。

二、对于Managed/Bare的工作流以及本地环境

在我看来，Managed 和 Bare 的差别不是“是否更专业”，而是“谁来驱动原生工程”。Managed 的出发点是尽量不碰原生，把权限、依赖、清单、证书等改动写进 app.config.ts 与 Config Plugins；真正打包时，由 EAS 在云端“理解这些意图”，在一个干净的机房环境里完成预构建和打包。

而 Bare 则相反：你自己维护 ios/ 与 android/ 的一切，工程怎么组织、证书如何管、Gradle 和 Pods 的版本如何对齐，都要自己兜底。两条路都能到达终点，只是代价与自由度不同。

云端构建很慢，一个月也有次数限制（基本是够用的，只要不是天天打包浪费次数，尽量把需要的原生包装完）。

Expo prebuild

所谓 npx expo prebuild，正是这两条路之间的关节。

它会把 app.config.ts 与 Config Plugins 里声明的修改，真的落到原生工程：iOS 这边生成 Xcode 项目、写入 Info.plist 与 Entitlements、跑 CocoaPods。Android 那边改 AndroidManifest、Gradle、加仓库和权限。

EAS 云端打包在过程里也会做这件事，只不过那是发生在云端的临时目录里；而你本地执行 npx expo prebuild，会在仓库里生成或更新 ios/ 与 android/，等同于“把原生层交到你手里”。

也正因为如此，一旦你选择在本地长期维护这两个目录（并停止依赖 prebuild 自动回写），就意味着你已经进入 Bare 的工作流。

这个命令的本质是把 app.json/app.config.ts 与 Config Plugins 中声明的“原生意图”落地为真实原生工程，生成或更新