一、解析匹配到的规则路由-路由地址动态处理

在上文执行完的过程中会发生几种情况，咔咔这里给大家整理一下，由于写的比较多怕有时候看的时候就混淆了。

第一种情况

没有任何路由参数和路由规则，就单纯的路由地址。

在这里打印一下检测URL和规则路由是否匹配的返回结果，以下的几种情况都使用的同一个地方打印，就不在写第二次了。

也就是当路由地址为纯路由地址时返回的是一个空数组。

第二种情况

设置有路由参数并且是必选参数，会返回参数和值并且是数组形式。

第三种情况

设置有资源路由参数并且是必选参数，会返回参数和值并且是数组形式，如果没有参数则返回false。

接下来在进入到本节的正题，为什么要做对以上的三种情况做出声明，请看下图咔咔圈出来的地方。

以上三种情况的打印结果就是$match这个的值，所以当$match值为false时整个流程会直接返回false。

不会在去执行解析匹配到的规则路由这一步骤。

在这里会执行几个动作，分别为

• 检查OPTIONS请求
• 检查前置行为
• 解析匹配到的规则路由

而且我们要学习的就是解析匹配到的规则路由这个里边的内容。

使用以下路由作为案例进行执行流程。

解析匹配到的规则路由

参数说明

• $request ： object(think\Request) 请求类
• $this->rule ： string(13) "hello/<name?>" 路由规则
• $this->route ： string(17) "index/index/hello" 路由地址
• $url : string(5) "hello" 请求地址
• $option : array(1) { ["merge_rule_regex"] => bool(false)} 路由参数
• $match : array(1) { ["name"] => string(1) "1"} 就是上边三种情况返回的值

执行文件：thinkphp/library/think/route/RuleItem.php，行号202.

接着就会进入到方法parseRule这个里边，这个方法的功能就是解析匹配到的规则路由，参数就是咔咔上边给写出来的六个参数。

由于路由参数是没有设置的所以不会去执行上边的那部分，接下来会对圈起来的地方进行深入的解析。

在这里主要就是替换路由地址中的变量。

这里的route和match这俩个值在上边的参数就已经做出说明了，可以翻上去看一下。

可以肯定的是肯定这个判断肯定会进行执行。

这里注意一下中间的部分，可以看到$replace和$search执行了俩次。其实就是针对路由规则后边的地址进行了俩种方案。

路由规则后边的参数是可选的，所以说这俩个值分别为以下，请看图。

然后通过str_replace() 函数替换字符串中的一些字符（区分大小写）。

最后返回的route就是string(17) "index/index/hello"

接下来就是咔咔圈出来的地方，这块主要就是运用PHP函数来对请求地址进行的处理。

这里有一个方法作用是解析URL地址中的参数Request对象，但是因为URL在这里是个空值所以不会去执行。

在将三个值进行赋值，然后就开始执行了路由调度。

本节就简单说到这里，在本节主要就是解析匹配到的规则路由，接下来就是进行路由调度。

路由调度是路由这块的最后一个流程，也是连接控制器的一个点，接下来咔咔会对路由调度进行详细解析。

续集

在解析匹配到的规则路由中存在这行代码，在上文中没有做出对应情况说明，接下来对这种情况做出说明。

路由地址设置为如下。

此时在来打印一下刚刚那块的代码查看一下变化，到底有什么作用。

最后就是通过str_replace进行替换的，所以并将参数换成hello。

这里有一个非常重要的一个点就是关于str_replace这个函数的高级使用，平时都是用一个字符串替换另一个字符串，但是在本案例中是数组替换数组的方式。

如果你之前没有使用过这种方式，请自行搜索或者持续关注咔咔的发文，你会看到你想要的。

二、路由调度

在路由的这一节中这是咔咔最后讲解的一个重点，路由调度。

路由调度完就是控制器的执行了，不是说路由设置完就可以直接访问的。

在解析匹配到的规则路由的最后一步就会执行路由调度。

执行文件 ： thinkphp/library/think/route/Rule.php 763行.

参数说明

• $request ： object(think\Request) 请求类
• $route : string(17) "index/index/hello"
• $option : array(1) { ["merge_rule_regex"] => bool(false)}

那么就来到发起路由调度的方法来进行深度解析。

在这个方法中咔咔只对最常用的方式进行解析了，其它的方式根据自己阅读源码的方式进行阅读即可。

来到解析URL地址为 模块/控制器/操作中。

关于这个list的使用在源码中也出现了很多次了，咔咔将打印结果给大家展示出来。、

打印的数据为$this->parseUrlPath($route);

接下来在一张图中进行打印$path和$var的值，你们就知道这个list是怎么使用的。

从下图中就可以看到list其实就是将数组的索引值赋值给list中的俩个变量而已。

接下来就是获取操作，控制器，模块。

函数array_pop就是返回数组的最后一组数据然后返回，在这里也就是返回的操作。

控制器也是用同样的操作。

模块是会在配置文件中获取，最终也是通过array_pop来进行获取的。

至于使用请求类来获取请求方式，这个在后期会进行解析，这里只需知道返回的是请求方式即可。

最终的返回结果如下图。

在这里有一个问题，就是关于类的调用问题，跟这咔咔的节奏一点一点追踪。

路由到模块/控制器/操作类的调用关系

追踪这个函数第一步是进入到了类thinkphp/library/think/route/Rule.php这里

然后在进行追踪Modul这个类。

又因为这个类继承着Dispatch这个类，所以还需要在继续追踪。

来到thinkphp/library/think/route/Dispatch.php就可以看到这个构造函数，到这里也就是最后一步了。

然后在通过本类thinkphp/library/think/route/Dispatch.php的init方法，返回本类，也就是上层打印出来的结果。

在这里可以对这个返回结果做一个调试看一下结果。

通过结果就知道最终就是从这里返回过去的。

三、路由调度的最终结果返回给了谁？

路由调度的解析在这里就结束了，但是经过了一层一层的深扒已经进入到了框架的最底层位置了。

这个时候突然给返回了一个值，是不是有点懵，这是返回到哪里去了。

根据咔咔画的思维导图先来捋一遍。

• 路由到模块/控制器/操作$this->dispatchModule
• 发起路由调度$this->dispatch
• 解析匹配到的规则路由return $this->parseRule
• 执行 $this->checkRule检测路由
• 执行think\route\RuleItem Object 中的check
• 检查分组路由
• 检测分组路由 ： parent::check
• 检测域名路由
• 路由检测： this->route->check(must);
• 路由检测 ： $this->routeCheck()->init()

所以说根据咔咔的导图最开始的位置就是$this->routeCheck()->init()

如果图不清晰请及时在评论区见。

也就是返回到了下图位置。

然胡使用咔咔提供的神器来打印一下执行流程。

这里跟上边那个无序列表时反向的，跟这个流程执行也是一一致的。

截止到这里关于路由的所有内容就结束了，在路由这节有很多的内容，也不会去全面的解读，抓住要点进行解析即可。

总结

在这一节中主要针对解析匹配到的规则路由-路由地址动态处理，主要就是针对不同的路由规则参数，返回不同俩种结果。

主要就是针对上文中的一种情况就是路由规则和路由地址都带有参数时对参数进行的处理。

然后使用array_pop进行获取模块控制器方法，最终执行到路由调度。

在路由调度后一定要清晰的知道关于返回值是返回给了哪里，对执行的流程一定明确，可以根据咔咔给出的导图，或者使用神器来打印也可以。

路由源码解析到这里就大结局了，从应用初始化开始到路由调度返回值，这一个过程中有很多的过程，咔咔也仅仅是针对重要的进行了解析。

后期如有时间也会对其它情况进行详细的说明，路由这块也是框架最复杂的一部分，希望可以好好进行理解。