为什么还要再造一个基于文件的路由插件？
在 React Router 6 之后，官方已经提供了多种便捷的路由配置方式，包括最近比较火的基于文件夹的路由插件。但是在实际项目中，我们仍然选择手搓了一个「类似 Next.js 风格」的文件路由插件。或许你会疑惑：为什么要多此一举？ 下面整理了几点思考，与大家分享。
1. 更贴合国内前端常见的目录结构与习惯
在许多国内 React 项目中，前端开发者更偏爱一种简洁明了的目录组织方式：
pages文件夹中每个子目录或文件就代表一个页面；- 编写页面时不需要额外维护路由配置文件，也不用手动引入、注册路由；
- 路由与文件夹结构“天然对应”。
Next.js 的「约定式路由」理念在这点上已经非常成熟，却往往意味着需要在 Node 环境下运行 SSR 或 SSG。对于仅需要纯前端打包、并在任意静态服务上就能直接跑的场景而言，Next.js 的全套方案并不适用（或门槛较高）。
基于文件的路由插件正好能兼顾这两方面：借鉴 Next.js 的约定式路由思路，让每个页面看起来一目了然；同时又保留前后端分离的传统部署模式，不用强制依赖 Node。
2. 无需部署 Node，使用场景更灵活
对许多个人项目或中小团队而言，部署 Node 服务器是一件“多余或麻烦”的事情。例如：
- 一些老旧的运维环境只有 Nginx 或 Apache，想要增加 Node 就需要配额外服务器或改造部署流程；
- 团队里对 SSR 并没有需求，也不想因为 Next.js 的打包、路由和 SSR 环节而增加学习和维护成本；
- 更倾向于静态化部署，只要把打包产物丢到 CDN、OSS、GitHub Pages、Vercel 等就能访问。
官方的基于文件夹路由方案虽然提供了一些便利，但有时仍需和服务器端做交互，或者对配置做一定的额外学习和约定。而我们设计的这个插件，目标非常明确：
- 不依赖 Node
- 充分利用 React Router 的核心特性
- 让前端代码在更广泛的场景中可以直接跑起来
这样，只要把项目构建产物扔到静态服务器里，就能访问，不需要再为后端做特殊的环境准备。
3. 不仅是技术落地，更契合国内开发者习惯
由于 Next.js 的「约定式路由」在国外社区早已接受度很高，很多人习惯了这种“文件即路由”的思路。
在国内，虽然这个思路也很流行，但许多团队还在使用「配置式路由」或「多级目录 + index.tsx 维护路由表」。迁移到官方文件式路由插件或 Next.js 都需要做一番学习和改造。
因此，我们希望提供一条相对平滑的过渡途径：
- 能够保留 React Router 的原生特性和 API；
- 目录结构跟国内常见的“
pages/xxx就是一个路由”做法一致； - 让开发者“拿来即用”，无需付出高昂的学习或改造成本。
4. 与官方文件式路由并不冲突，适配层各有侧重
React Router 官方推出基于文件夹的路由插件，其实也极大地简化了手动配置路由的繁琐性。但要注意的是，官方方案的定位是“自动生成路由配置”，并在此基础上做了很多额外功能的演进，而这个项目更偏向于**“模拟 Next.js 路由”**。二者各有优劣：
-
官方插件：
- 功能完整、后续更新与 React Router 同步；
- 可能在特性覆盖或扩展性上更强，但改动也可能随 React Router 的迭代变化。
-
手搓文件路由：
- 更灵活，能够针对国内使用习惯或特定场景做精确的适配与裁剪；
- 对 Node 依赖要求更低，对部署流程的侵入更小。
所以我们并不是跟官方“竞争”，而是基于特定开发需求量身打造的一款插件。就好比官方的方案是一款多功能瑞士军刀，而我们做了一个更小、更符合特定场景的工具，你可以根据项目需求自由选择。
5. 总结
- 更符合国内常见目录结构：减少心智负担，文件夹即路由，写页面就等同于写路由。
- 无需部署 Node：前后端分离的静态部署场景，一样能享受“约定式路由”的便利。
- 保留 React Router 精华：原生特性可随时直接拿来用，不必担心重度封装而引发的限制。
- 与官方方案互补：如果你想要一个更轻量、更贴近 Next.js 的使用方式，可以考虑这个插件；如果你要更全功能、更长远的维护，官方方案也是不错选择。
希望通过这个文档，能让你了解我们为什么要“再造一个轮子”：不是想跟官方抢地盘，而是有许多团队和个人开发者确实并不想（或无法）部署 Node，却又偏爱 Next.js 的“约定式”优势。在这样的背景下，这个插件可以很好地满足他们的需求。
如你对此有更多想法或需求，欢迎在仓库提 Issue 或 PR，一起完善这条让「文件即路由」更轻松走进国内业务的道路！