Hyperf 默认使用 Nikic/FastRoute 作为路由器。
它的本质是：FastRoute 是一个基于正则表达式编译和前缀树/分派树 (Dispatch Tree)的轻量级 HTTP 路由器。它不依赖传统的线性遍历或简单的字符串匹配，而是在启动阶段将所有路由规则编译成一个高效的数据结构（通常是嵌套数组或状态机）。在运行时，它通过极少的 CPU 指令就能确定请求是否匹配以及提取参数。这是一种牺牲少量启动时间和内存，换取极致运行时性能 (O(1) 或 O(log N) 复杂度)的设计哲学。
如果把路由匹配比作查字典：
- 传统线性路由 (Linear Match)：是从头到尾翻书。
- 流程：第一条路由
/api/user？不是。第二条/api/order？不是……直到找到或翻完。 - 缺点：路由越多，查找越慢。O(N) 复杂度。
- 流程：第一条路由
- FastRoute：是按首字母索引的快速检索系统。
- 流程：
- 看第一个字母
/-> 进入/分支。 - 看第二个字母
a-> 进入api分支。 - 看第三个部分
user-> 直接定位到user节点。
- 看第一个字母
- 优点：无论字典有多少页，只要索引建立得好，查找速度几乎恒定。O(1) 或 O(K) 复杂度（K 为 URL 层级深度）。
- 核心逻辑：别在运行时做决定，要在启动时把地图画好。运行时只是拿着地图走迷宫，而不是现场探路。
- 流程：
一、核心原理：它是如何工作的？
FastRoute 的工作分为两个阶段：数据生成 (Data Generation)和数据分发 (Data Dispatching)。
1. 启动阶段：数据生成 (Compilation)
- 输入：所有定义的路由（来自注解或配置文件）。
GET /user/{id}POST /userGET /order/{orderId}
- 处理：
- 分组：按 HTTP 方法（GET, POST…）分组。
- 正则化：将动态参数
{id}转换为正则捕获组(\d+)（如果有约束）。 - 构建树：构建一个静态分派树 (Static Dispatch Tree)。
- 根节点：
/ - 子节点：
user,order - 叶子节点：包含回调函数和参数提取规则。
- 根节点：
- 序列化：将这个巨大的数组结构序列化为 PHP 代码或缓存文件。
- 输出：一个巨大的、优化的 PHP 数组（Dispatch Map）。
2. 运行阶段：数据分发 (Dispatching)
- 输入：HTTP 请求的方法（GET）和路径（
/user/123）。 - 处理：
- 查找方法表：从缓存数组中取出
GET对应的子树。 - 逐层匹配：
- 检查路径是否以
/user/开头？是。 - 剩余部分
123是否匹配正则\d+？是。
- 检查路径是否以
- 提取参数：捕获
123作为id。 - 返回结果：返回
[handler, params]。
- 查找方法表：从缓存数组中取出
- 输出：控制器类名和方法名，以及参数数组。
💡 核心洞察：FastRoute 的核心魔法在于“预计算”。它将复杂的路由匹配逻辑，转化为了简单的数组查找和正则执行。
二、数据结构：Dispatch Map 长什么样？
虽然实际结构更复杂，但概念上类似这样：
$dispatchMap=['GET'=>[// 静态路由'/home'=>['HomeController','index'],// 动态路由树'/user/'=>[// 子树：匹配 {id}['regex'=>'~^(\d+)$~',// 正则'suffix'=>'',// 后缀'handler'=>['UserController','show'],// 处理器'paramNames'=>['id']// 参数名映射]],'/order/'=>[// ...]],'POST'=>['/user'=>['UserController','create'],]];- 静态部分：直接键值查找，极速。
- 动态部分：正则匹配，但范围被静态前缀大大缩小。
三、性能优势：为什么选它？
1. 极低的时间复杂度
- 线性路由：1000 条路由，平均匹配 500 次。
- FastRoute：1000 条路由，通常只需几次数组查找 + 1 次正则匹配。
- 结果：在高并发下，CPU 消耗显著降低。
2. 零依赖与轻量级
- FastRoute 只有一个文件核心逻辑，无外部依赖。
- 内存占用小，适合常驻内存应用（Swoole/Hyperf）。
3. 与 Swoole/Hyperf 的完美契合
- 启动一次，运行万次：Swoole 进程启动时编译路由，之后每个请求都复用这个编译好的结构。
- 无锁竞争：路由表是只读的，多协程并发读取无需加锁。
4. 标准兼容
- 完全符合 PSR-7 (HTTP Message) 和 PSR-15 (Middleware) 标准。
四、认知牢笼：常见误区
1. 误区：“FastRoute 支持所有正则特性。”
- 真相：为了性能，FastRoute 对正则有一些限制。例如，不支持 lookahead/lookbehind 等复杂断言，因为它们会破坏树的构建逻辑。
- 对策：保持路由正则简单（如
\d+,[a-z]+）。复杂验证留给 Controller。
2. 误区：“路由越多，FastRoute 越慢。”
- 真相：FastRoute 的性能随路由数量增长非常平缓（对数级或常数级）。即使有几千条路由，性能损耗也可忽略不计。
- 对策：放心定义细粒度路由，不必为了性能强行合并。
3. 误区：“我可以动态添加路由。”
- 真相：FastRoute 的路由表是不可变 (Immutable)的。运行时不能
addRoute()。 - 对策：所有路由必须在启动阶段定义完毕。如果需要动态路由，需使用中间件转发或自定义 Router 实现（不推荐）。
4. 误区：“FastRoute 比 Nginx 路由快。”
- 真相：Nginx 的
location匹配是在 C 层进行的，且发生在请求到达 PHP 之前。Nginx 永远比 PHP 层路由快。 - 对策：在 Nginx 层处理静态文件、重定向、限流。让 FastRoute 只处理业务逻辑路由。
5. 误区：“修改了路由注解，FastRoute 会自动更新。”
- 真相：FastRoute 的数据是缓存的。修改注解后，必须清除缓存或重启服务，重新触发编译过程。
- 对策：开发环境使用
server:watch，它会自动检测变化并重启。
🚀 总结：原子化“FastRoute”全景图
| 维度 | 关键点 |
|---|---|
| 本质 | 基于预编译分派树的高性能 HTTP 路由器 |
| 核心算法 | 静态前缀匹配 + 动态正则捕获 |
| 工作阶段 | 启动时编译 (Compile) -> 运行时分发 (Dispatch) |
| 性能特征 | O(1)/O(log N) 查找，极低 CPU 开销 |
| 主要优势 | 轻量、无依赖、适合常驻内存、PSR 兼容 |
| 常见陷阱 | 运行时不可变、复杂正则受限、需清除缓存 |
| PHP 隐喻 | Hash Map Lookup vs. Linear Array Search |
| 公式 | Request_Latency = (Tree_Traversal_Time + Regex_Match_Time) |
终极心法：
FastRoute 的本质，是“用空间换时间，用预计算换实时性”。
别在每次请求时都重新思考路怎么走。
把地图刻在脑子里，脚步自然轻盈。
于编译中见智慧，于分派见速度；以静态为尺，解动态之牛，于网络入口中，求极速之真。
行动指令：
- 查看缓存：去
runtime/container/proxies/或类似目录，找找看有没有包含route字样的缓存文件，看看生成的 PHP 数组结构。 - 优化正则：检查路由中的正则，确保它们尽可能简单。
- 压力测试：对比增加 100 条路由前后，QPS 的变化，验证 FastRoute 的稳定性。
- 思维升级：记住，路由是系统的门面。一个高效的路由器，是高并发应用的第一块基石。