深入解析 Django 请求处理流程：从 WSGI 到响应生成的完整链路

前言

在最近的一次技术面试中，面试官提出了一个关于 Django 内部机制的问题：`request.user` 属性中的用户对象究竟是如何获取的？当时未能给出准确回答，这促使我查阅相关文档并深入阅读 Django 源码，特此整理总结这一关键知识点。

要理解为何可以直接通过 `request.user` 访问当前用户，首先需要梳理 Django 处理请求并返回响应的整体流程。本文将重点总结 Django 框架在处理单个 HTTP 请求过程中所经历的关键步骤。

WSGI

当客户端发起请求时，最先接收到该请求的实际上是 Web 服务器（如 Nginx 或 Apache）。WSGI（Web Server Gateway Interface）的作用正是作为 Web 服务器与 Web 框架（如 Django）之间的桥梁。WSGI 规范分为服务端和应用端两部分：服务端负责执行应用程序并向应用端提供一个回调函数，应用端则负责处理具体请求，并通过该回调函数将响应结果返回给服务端。

从本质上看，WSGI 充当了 Web 服务器与 Django 应用之间的通信中介。

数据流

当用户向应用发送请求时，WSGI Handler 会被初始化，并执行以下一系列操作：

1. 导入 `settings.py` 配置文件及 Django 的异常处理类。
2. 调用 `load_middleware` 方法，加载 `settings.py` 中 `MIDDLEWARE_CLASSES`（旧版）或 `MIDDLEWARES` 元组内定义的所有中间件类。
3. 创建四个列表：`_request_middleware`、`_view_middleware`、`_response_middleware` 和 `_exception_middleware`，分别用于存储处理请求、视图、响应和异常的方法。
4. WSGI Handler 实例化一个 Django HTTP 请求对象，具体类型为 `django.core.handlers.wsgi.WSGIRequest`。
5. 遍历 `_request_middleware` 列表，按顺序依次调用其中的处理请求方法。
6. 解析请求的 URL 路径。
7. 遍历 `_view_middleware` 列表，依次处理视图相关逻辑。
8. 若匹配到对应的 URL 规则，则调用相应的视图函数。
9. 处理可能发生的异常，执行 `_exception_middleware` 列表中的方法。
10. 遍历 `_response_middleware` 列表，按从内向外（与请求中间件顺序相反）的顺序调用处理响应的方法。
11. 最终生成响应对象，并调用 Web 服务器提供的回调函数将数据返回。

中间件

Django 利用中间件实现多项核心功能，例如通过 CSRF 中间件防止跨站请求伪造攻击。此外，会话数据管理、身份认证及授权等功能也均由中间件完成。开发者还可以编写自定义中间件，以调整或“短路”应用程序的数据流。

Django 中间件至少包含以下四个方法之一：`process_request`、`process_response`、`process_view` 和 `process_exception`。这些方法会被 WSGI Handler 收集并按特定顺序调用。

process_request

以 `django.contrib.auth.middleware.AuthenticationMiddleware` 为例进行分析：

def get_user(request):
 if not hasattr(request, '_cached_user'):
  request._cached_user = auth.get_user(request)
 return request._cached_user

class AuthenticationMiddleware(MiddlewareMixin):
 def process_request(self, request):
  assert hasattr(request, 'session'), (
    "The Django authentication middleware requires session middleware "
    "to be installed. Edit your MIDDLEWARE%s setting to insert "
    "'django.contrib.sessions.middleware.SessionMiddleware' before "
    "'django.contrib.auth.middleware.AuthenticationMiddleware'."
  ) % ("_CLASSES" if settings.MIDDLEWARE is None else "")
  request.user = SimpleLazyObject(lambda: get_user(request))

通过观察上述代码可以发现，`request.user` 属性正是在 `AuthenticationMiddleware` 中生成的。具体机制将在后续详细阐述。

该中间件仅实现了 `process_request` 方法，表明它仅在请求流入 Django 应用时处理数据流。该中间件首先验证是否启用了会话中间件，随后通过调用 `get_user` 函数来设置用户对象。当 WSGI 处理程序迭代

`process_request` 方法列表时，它会构建最终传递给视图函数的请求对象，从而使开发者能够引用 `request.user`。若某些中间件未定义 `process_request` 方法，则在此阶段会被跳过。

`process_request` 方法应返回 `None` 或 `HTTPResponse` 对象。若返回 `None`，WSGI Handler 将继续执行后续的 `process_request` 方法；若返回 `HTTPResponse` 对象，则处理流程将被“短路”，直接跳过视图处理并进入 `process_response` 循环。

解析 url

当所有 `process_request` 方法执行完毕后，我们将获得一个已处理好的请求对象，该对象将被传递给视图函数。在此之前，Django 必须解析 URL 并确定调用哪个视图函数。此过程相对简单，主要依赖正则表达式匹配。`settings.py` 中的 `ROOT_URLCONF` 键指定了根 URL 配置模块，其中包含了所有应用的 `urls.py` 文件。若未匹配到任何规则，将抛出 `django.core.urlresolvers.Resolver404` 异常，这是 `django.http.HTTP404` 的子类。

process_view

此时，WSGI Handler 已明确知道应调用哪个视图函数及其参数。Handler 会再次调用中间件列表中的方法，此次针对的是 `_view_middleware` 列表。所有 Django 中间件的 `process_view` 方法声明如下：

process_view(request, view_function, view_args, view_kwargs)

与 `process_request` 类似，`process_view` 函数必须返回 `None` 或 `HTTPResponse` 对象。若返回 `None`，WSGI Handler 将继续处理视图；若返回响应对象，则“短路”处理流程并直接返回响应。例如，CSRF 中间件实现了 `process_view` 方法：当存在有效的 CSRF Cookie 时，该方法返回 `None`，视图函数继续执行；否则，请求将被拒绝，处理流程被“短路”，并生成错误信息。

进入视图函数

一个有效的视图函数需满足以下三个条件：

• 必须是可调用对象。这包括基于函数的视图或基于类的视图（继承自 `View` 并使用 `as_view()` 方法使其可调用）。这些方法的调用依赖于 HTTP 动词（如 GET、POST 等）。
• 必须接受一个 `HttpRequest` 对象作为第一个位置参数。该 `HttpRequest` 对象是所有 `process_request` 和 `process_view` 中间件方法处理后的结果。
• 必须返回一个 `HttpResponse` 对象，或者抛出一个异常。正是这个响应对象触发了 WSGI Handler 的 `process_response` 循环。

process_exception

如果视图函数抛出异常，Handler 将遍历 `_exception_middleware` 列表，这些方法按相反顺序执行，即从 `settings.py` 中列出的最后一个中间件到第一个。若某个异常被抛出，处理过程将被短路，后续的 `process_exception` 方法将不再执行。通常我们依赖 Django 的 `BaseHandler` 提供的异常处理程序，但也可以使用自定义的异常处理中间件。

process_response

在此阶段，我们已获得一个 `HttpResponse` 对象，该对象可能由 `process_view` 返回，也可能由视图函数直接返回。接下来，我们将循环访问响应中间件。这是中间件调整数据的最后机会。执行顺序是从内向外进行。

以 Cache 中间件的 `process_response` 为例：它依赖于应用内的不同状态（如缓存是否开启、是否在处理数据流等），来决定是否缓存响应内容。

注意

Django 1.10 及之前版本与后续版本的区别：

在旧版本的 `MIDDLEWARE_CLASSES` 中，即使某个中间件“短路”了执行过程，所有中间件仍会调用其 `process_response` 方法。而在新的 `MIDDLEWARES` 配置中，只有触发短路的中间件及其之前执行的中间件才会调用 `process_response` 方法。

总结

以上即为 Django 处理单个请求的基本流程。最终，Django 的 WSGI Handler 会创建一个基于 `HttpResponse` 的返回值，并调用回调函数将数据传递给 Web 服务器，最后返回给用户。

以下是两个关键点：

我们现在已清楚视图函数如何与 URL 解析器匹配，以及是谁（WSGI Handler）调用了它。

存在四个关键挂钩点可介入请求/响应周期：`process_request`、`process_response`、`process_view` 和 `process_exception`。请求中间件从外部向内执行，最终抵达视图函数；随后通过响应中间件从内向外返回。

参考资料

• Django Middlewares and the Request/Response Cycle
• How Django processes a request

总结

以上就是本文的全部内容，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，如果有疑问大家可以留言交流，谢谢大家对本站的支持。