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路由？如果还没试过，阻碍你的是技术顾虑，还是根本不知道它能这么用？
热门跟贴