Content

Router 指负责管理应用内部路径、页面切换与状态映射的路由机制。在前端和客户端开发里，它的作用不只是“跳页面”，而是决定 URL、界面结构、导航状态与组件组织之间如何建立稳定关系，因此常常是应用架构中的骨架层。

Acceptance

路由(Router)的本质问题:用户做了某个动作后,应该显示哪个界面?

三代演进:

1. 服务端路由 (1990s-2010s): 每个 URL 对应服务器上的一个文件或函数。每次导航 = 浏览器刷新整个页面。
2. 客户端路由 / SPA (2010s): JS 拦截导航事件,用 History API 修改 URL,动态替换页面内容。代表:React Router (2014)。只有一个 HTML,JS 做路由。
3. 文件路由 (2020s): 文件路径 = 路由路径。不需要写路由表,文件在就是路由在。代表:Next.js App Router, Expo Router。

跨平台的路由本质:

Android 开发者不觉得 Intent 是”路由”——但本质是同一件事:标识符→界面的映射。

Question

• 文件路由的”文件在=路由在”模型,在大型项目中是否会导致 app/ 目录过于庞大?有什么应对策略?
• Expo Router 底层仍是 React Navigation——这种”高层抽象包装低层库”的模式有什么风险(版本耦合、行为泄漏)?
• 如果 Android 的 Intent 也是路由,为什么 Android 社区从未发展出”路由库”的概念?

See Also

• Tailwind — 同为”Web 概念移植到移动端”的案例

• AST — Expo Router 底层的 Babel 编译基于 AST

• MindGym M0 session (2026-04-13) — 路由发源和跨平台对比讨论

• 用户背景:Android 原生开发出身,初次接触”路由”概念

• Expo Router 官方文档

• React Navigation 官方文档

• Android 官方文档：Intent / Navigation

YoYo’s Note

路由这个概念的有趣之处在于:它在不同平台上被不同的名字掩盖了。Android 叫 Intent + Activity,iOS 叫 push/pop,Web 叫 URL routing。但剥开名字,底层都是”一个映射表+一个导航栈”。React Native 把 Web 的路由词汇带进了移动端,这不是因为移动端”需要”路由,而是因为 RN 的开发者来自 Web,他们带着已有的心智模型来命名事物。

Expo Router 的”_layout 不是注册表”这个认知纠正很关键——它是文件路由和代码路由的核心分界线。React Navigation 需要注册,Expo Router 不需要。

Answer

文件路由的”文件在=路由在”模型,在大型项目中是否会导致 app/ 目录过于庞大?有什么应对策略?

会,尤其在页面很多、嵌套路由深、同时存在多端入口时,app/ 很容易膨胀成一个巨型目录。常见应对方式包括按路由分组拆文件夹、把业务组件下沉到独立 feature 目录、用 route groups 组织结构而不直接暴露 URL,以及把“页面壳”和“业务实现”分离。也就是说,文件路由适合表达入口,不适合把全部业务逻辑都堆在入口层。

Expo Router 底层仍是 React Navigation——这种”高层抽象包装低层库”的模式有什么风险(版本耦合、行为泄漏)?

常见风险是上层承诺的简洁心智模型,会在边界场景下被下层真实行为打穿。比如版本升级节奏不一致、某些高级导航能力仍要回退到底层 API、或者报错信息直接暴露 React Navigation 语义。这类封装的价值在于简化主路径,但代价是你在复杂场景下仍要理解底层。

如果 Android 的 Intent 也是路由,为什么 Android 社区从未发展出”路由库”的概念?

一种可理解的解释是,Android 的导航能力长期被系统 API 和平台组件直接托管,开发者默认就把它视为平台能力,而不是需要额外抽象的一层。Web 社区之所以强烈发展出 Router 概念,是因为浏览器最初只会整页跳转,SPA 时代必须自己补出一层导航抽象。也就是说,不是 Android 不需要路由,而是它很早就被平台吸收掉了。