Build Log / 技术选型

为什么我放弃了
React Native，选择了 Expo

在做 FlexiLog Mobile 时，我更想把时间花在打卡体验上，而不是把移动端项目的基础设施从头接起来。

2026 年 10 月 4 日·5 分钟阅读·阿策搞AI

先把标题说准确：Expo 仍然基于 React Native。我没有换掉 React Native 的组件和原生运行方式；我放下的是“从一个裸项目开始，自己拼路由、常用原生模块和构建流程”的开局方式。这是一个人做产品时的取舍，不是一场框架胜负。

选型先看产品要做什么

FlexiLog Mobile 是一款本地优先的健身日志。它要处理四个 Tab、离线记录、每日提醒、生物识别锁、从相册选头像，以及把周报海报保存到手机。核心难点是把这些能力连成顺手的使用流程，而不是证明我能维护多少原生工程配置。

因此我最终采用 Expo SDK 54、React Native 0.81 和 Expo Router。下面三点，直接影响了开发节奏。

项目的首页、日历、计划、设置都放在 app/(tabs)/ 下，由 Expo Router 组织导航。打开目录就能看出页面边界，改一个页面时也更容易定位相关代码。路由不替我设计产品，但少了一层自己维护的导航胶水。

运动记录放在 expo-sqlite；打卡提醒用 expo-notifications；解锁用 expo-local-authentication；选头像、保存海报分别用到图片与媒体库模块。这些都是项目实际需要的能力，选型时能围绕需求逐个验证。

日常用 npx expo start 迭代；需要本地原生构建时，用 npx expo run:ios 或 npx expo run:android。项目也配置了 EAS 构建，但不把云构建当作唯一出路。对我来说，重要的是知道改了配置或原生依赖后，该在哪一步重新构建。

Expo Go 不是所有项目的最终调试环境。项目需要的原生库或配置不在 Expo Go 里时，就要使用适合项目的开发构建或本地原生构建。不能把“扫码能打开”当作功能全部验证过。
原生工具链仍然存在。在 iOS 和 Android 上构建应用，仍要处理 Xcode、Android 工具链、签名和权限。修改原生依赖或应用配置后，也不能只刷新 JavaScript 就期待新能力生效。
真机网络和模拟器不同。FlexiLog Mobile 的 AI 功能访问自建代理。iOS 模拟器可以用本机地址调试，真机不能把电脑上的 localhost 当成服务器；发布构建还要使用可访问的 HTTPS 地址。这和选 Expo 还是裸项目无关，却很容易在最后一步暴露。

如果是从零做一款以业务体验为主的 iOS / Android 应用，我会先用 Expo 验证路由、原生能力和构建链路，再决定是否需要更深的原生定制。

如果已经有成熟的 React Native 裸项目和稳定的原生工程，我不会仅因为 Expo 省事就迁移。Expo 也能接入原生代码，真正需要比较的是现有工程成本、团队习惯和具体需求。

我选 Expo，是为了让“做出好用的健身日志”占据更多时间。React Native 仍在底层；只是日常工作里，我希望先面对产品问题，再面对工程接线问题。