在上篇文章中我们我们已经已经知道request在Django中的过程，如果没有看过上篇文章 Django系列：请求的生命周期（1）的，可以先看一下，已对你对本文有更好的理解。
本文着重讲解当一个request来到Django后， 是如何进行视图函数或视图类的匹配的，以及如何正确调用请求方法，下图就是当request进来时所要进行请求解析的入口源码：
那么 self.resolve_request(request) 这句代码的背后究竟干了什么了呢？
我们在开发新应用的过程中，都需要用到 urls.py 这个路由文件，那么我们先了解一下：include，path, re_path 三个函数都是干什么的:
注意：from django.conf.urls import url 中url函数将会被弃用，所以我们不讨论该函数
from django.urls import re_path, path, include
（1）：def include(arg, namespace=None)
参数：
arg：tuple | module，本质上是一个包含 urlpatterns 变量的 urls.py 文件模块
（a）: 当为元组时， 必须是二元素元素，args=（urlconf_module, app_name），urlconf_module是定向应用或根项目 urls.py 文件的路径，app_name可以是应用名称；
（b）: 当为模块变量是，其模块是包含有 urlpatterns 的变量
namespace：命名空间，当namespace存在时，app_name必须存在
返回值：(urlconf_module, app_name, namespace) 三元组；urlconf_module 是一个模块变量
（2）：path 和 re_path 都是路由系统，只不过 re_path 的路径包含正则表达式而已
（3）：当整个Django项目启动后，会根据ROOT_URLCONF的配置，形成一个链式的路由系统，请求匹配最终需要该类：django.urls.resolvers:URLResolver 解析，经调试候在代码的样子大致如下：
(4)：好了， 现在我们知道请求解析匹配的类，那么我们具体看看是如何匹配的，在（1）处时，已经知道请求的入口了，就是这句代码：
callback, callback_args, callback_kwargs =self.resolve_request(request)
resolve_request 方法的可信在这2句代码，请看下图：
resolver = get_resolver()：resolver 其实就是（3）提到的URL解析类：django.urls.resolvers:URLResolver， resolver = <URLResolver 'config.urls' (None:None) '^/'>， 对于resolver 的 urlpatterns 属性，它又是链式的。
resolver.resolve(request.path_info)，它返回的是一个 django.urls.resolvers:ResolverMatch类，其实ResolverMatch是一个元组，因为它实现了 __getitem__ 魔法函数， 返回值就是 ：
callback： 视图类， CBV.as_view() 函数
callback_args：请求的非关键字参数
callback_kwargs ：请求的关键字参数
至此，我们知道请求最终解析后的样子，那么他最终执行视图函数返回Response实例：
response = wrapped_callback(request, *callback_args, **callback_kwargs)
（5）：当试图函数执行后，经过 模板中间件、response渲染、异常中间件后，response 再次执行中间件的process_response方法，注意是逆序执行，最终到达第一个中间件后返回wsgi或uwsgi服务器，然后返回给浏览器。
