Django请求的生命周期

我们先来简单介绍一下 Django 是如何处理网络请求的。所有的网络请求，都是从 Request 开始，以 Response 结束。Django 的作用就是把来自客户端的 Request 经过处理，返回 Response。 完整的处理流程可以参考下图：

这里我们可以看到，绿的的箭头代表处理 HTTP Request 的工作流走向，红色的箭头代表处理 HTTP Response 的工作流走向。

首先，HTTP Request 是来自客户端，这里的客户端不仅仅是浏览器，也有可能是终端程序，还有可能是其它程序发送的网络请求，我们统称这些为客户端。

客户端发送网络请求， WSGI 首先接受处理。这里的 WSGI 全称是 Web Server Gateway Interface，是 Python 定义的 WSGI 程序和 WSGI 服务器之间的一种接口。项目中的 Peekpa/wsgi.py 里的代码就是实现的这个功能。它会将对网络请求做一次封装，然后将结果传递给 Django 中间件。

接着 Django 中间件接受用户请求，中间件的代码配置位置是在 项目名/settings.py 文件中的 MIDDLEWARE 变量：

MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
]

如上所示的中间件列表，它有很强的顺序性。这里只要记住一点： 处理 HTTP Request 是按照序列从 0 开始，一直到最后一个元素，依次按顺序处理；处理 HTTP Response 是按照从最后一个元素开始，0 号元素结尾，依次按顺序处理。这里的中间件我们会在之后的实验详细讲解。

当中间件处理完 HTTP Request 之后，Resquest 就来到了路由系统。这个其实就是我们的 项目名字/urls.py 文件。但是伴随着开发的进行，我们的路由配置文件可能还会细化到每个 Django App 中。

当 HTTP Request 根据自己的 URL path 找到了匹配的视图函数，它就会被交给指定的视图函数进行处理。在视图函数这里，程序有可能需要通过 ORM 和数据库交互，也有可能直接返回 HTML 模板数据。

视图函数处理完成之后，它会返回一个 HTTP Response 给中间件。

中间件再遵循我们上面说的，一层一层处理 HTTP Response，最终传递给 wsgi，然后 wsgi 返回给用户。

这样， Django 的一次请求就完成了。