Expo把API路由藏了2年，70%开发者压根没发现

React Native生态里有个冷知识：Expo Router从v2开始内置了完整的API路由能力，但官方文档把它塞在"高级功能"章节，导致大部分团队还在额外搭Node服务。

这有点像iPhone的背面轻点截屏——功能明明出厂就有，用户却以为要装第三方App。

文件系统即路由，但这次是后端

Expo Router的核心卖点是"文件系统即路由"。你把about.tsx丢进app/目录，自动获得/about路径。动态路由用方括号：[id].tsx匹配任意ID。

API路由遵循完全一致的命名规则，只是后缀换成+api.ts。

比如app/api/hello+api.ts直接暴露/api/hello端点。支持GET/POST/PUT/DELETE标准方法，返回标准Response对象。不需要express，不需要next，不需要单独部署Vercel函数。

一个文件同时解决前后端路由，这在移动端开发里相当罕见。传统方案里，React Native调API至少要跨三个仓库：客户端代码、BFF层、网关配置。Expo Router把中间层压缩成了一个文件目录。

谁在用？小团队省服务器，大团队省对齐成本

Expo官方没公布过API路由的采用率，但从GitHub Issue的活跃度和Discord讨论来看，知道这个功能的开发者估计不到三成。

知道的人里，用法分两类。

一类是独立开发者和小团队。他们的典型场景：App需要用户登录，但不想维护单独的Auth服务。直接在Expo项目里写app/api/auth+api.ts，处理JWT签发和校验。部署时走EAS（Expo Application Services），服务端逻辑跟着客户端一起打包上线。

另一类是中型团队的MVP阶段。产品还没验证PMF，先别急着拆分微服务。API路由充当临时BFF，等业务稳定后再决定是否迁移。

有个细节很能说明问题：Expo Router的API路由默认运行在Edge Runtime，冷启动比传统Node服务快一个数量级。对移动端场景来说，这意味着推送触达后的首屏加载可以省掉一次往返延迟。

限制也很实在

这个功能不是银弹。Expo团队自己列了几条红线：

数据库连接池别往里塞。Edge Runtime的生命周期短，长连接会频繁断开重连，性能反而更差。需要持久化存储的场景，建议走外部服务。

文件上传有体积限制。大文件分片或直传OSS更靠谱。

复杂业务逻辑建议尽早迁移。API路由的设计初衷是"轻量后端"，不是取代完整的Node服务。当端点超过20个或需要队列/缓存/搜索等中间件时，该拆就拆。

换句话说，它解决的是"有没有"的问题，不是"强不强"的问题。

为什么官方不主推？

Expo的商业模式值得琢磨。EAS按构建次数和并发收费，API路由跑在Edge上，对Expo来说边际成本极低。理论上他们应该大力宣传这个功能，吸引更多团队上船。

实际策略却相当克制。文档位置偏、示例代码少、发布会几乎不提。一种可能的解释：API路由的存在会冲击EAS的"自定义构建"付费点——如果后端逻辑都能塞在一个项目里，团队对独立CI/CD的需求就会下降。

另一种更务实的解释：React Native社区对"全栈框架"有历史创伤。早期尝试类似路线的框架（比如Meteor）都死于复杂度失控。Expo选择低调上线，让早期采用者先踩坑，比高调推广后翻车更安全。

有个数据可以参考：Expo Router v3的更新日志里，API路由的改进条目占了服务端相关更新的60%以上。说明团队在持续投入，只是不声张。

你现在的React Native项目，后端是单独维护的服务，还是已经试过这种文件级API路由？如果还没试过，阻碍你的是技术顾虑，还是根本不知道它能这么用？