前言
最近面试的时候，被面试官问道一个问题，就是 request.user 里面的 user 是怎样得到的，这个问题当时没有回答上来，可以说是非常的尴尬，所以赶快查了一些资料，看了一些源码，特地来总结一下这个问题。
要想回答为什么可以直接通过 request.user 得到请求的用户，应该先来看看请求被处理以及如何返回响应的流程。今天先总结一下 django 从请求到响应都进行了哪些过程。
WSGI
当客户端发送一次请求后，最先处理请求的实际上是 web 服务器就是我们经常说的 nginx、Apache 这类的 web 服务器，而 WSGI 的作用就是把 web 服务器和 web 框架 (Django) 连接起来。WSGI 被分为了两个部分：服务端和应用端。为了处理一个 WSGI 的响应，服务端执行应用程序并向应用端提供一个回调函数，应用端处理请求并使用提供的回调将响应返回给服务端。
本质上来讲，我觉得 WSGI 就是 web 服务器和 django 应用之间的一个联系人。
数据流
当用户向你的应用发送一个请求的时候，一个 WSGI handler 将会被初始化，它会完成以下工作：
中间件
中间件被用在了 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，说明它只在 request 这一步处理流入和流出 django 应用的数据流。这个中间件会首先验证会话中间件是否被使用，然后通过调用 get_user 函数来设置用户。当 WSGI 处理程序迭代
process_request 方法列表的时候，它将会构建这个最终会被传递给视图函数的请求对象，并能够使你引用 request.user。一些中间件没有 process_request 方法，在这个阶段，会被跳过。
process_request 应该返回 None 或者 HTTPResponse 对象。当返回 None 时，WSGI handler 会继续加载 process_request 里面的方法，但是后一种情况会短路处理过程并进入 process_response 循环。
解析 url
当所有的 process_request 被调用完之后，我们就会得到一个将被传递给视图函数的 request 对象。当这个事件发生之前，django 必须解析 url 并决定调用哪一个视图函数。这个过程非常简单，只需要使用正则匹配即可。settings.py 中有一个 ROOT_URLCONF 键来指定根 url.py，在这里会包含你所有 app 的 urls.py 文件。如果没有匹配成功，将会抛出一个异常 django.core.urlresolvers.Resolver404, 这是 django.http.HTTP404 的子类。
process_view
到这一步之后 WSGI handler 知道了调用哪一个视图函数，以及传递哪些参数。它会再一次调用中间件列表里面的方法，这次是_view_middleware 列表。所有 Django 中间件的 process_view 方法将会被这样声明：
process_view(request, view_function, view_args, view_kwargs)
和 process_request 一样，process_view 函数必须返回 None 或者 HTTPResponse 对象，使得 WSGI handler 继续处理视图或者'短路'处理流程并返回一个响应。在 CSRF middleware 中存在一个 process_view 的方法。作用是当 CSRF cookies 出现时，process_view 方法将会返回 None, 视图函数将会继续的执行。如果不是这样，请求将会被拒绝，处理流程将会被'短路'，会生成一个错误的信息。
进入视图函数
一个视图函数需要满足三个条件：
process_exception
如果视图函数抛出一个异常，Handler 将会循环遍历_exception_middleware 列表，这些方法按照相反的顺序执行，从 settings.py 里面列出来的最后一个中间件到第一个。如果一个异常被抛出，处理过程将会被短路，其他的 process_exception 将不会被执行。通常我们依赖 Djnago's BaseHandler 提供的异常处理程序，但是我们也可以使用自定义的异常处理中间件。
process_response
在这个阶段，我们得到了一个 HTTPResponse 对象，这个对象可能是 process_view 返回的，也可能是视图函数返回的。现在我们将循环访问响应中间件。这是中间件调整数据的最后的机会。执行的顺序是从内向外执行。
以 cache middleware 的 process_response 为例：它依赖于你的 app 里面的不同的状态（缓存是否打开或者关闭，是否在处理一个数据流），来决定是否缓存你的响应。
注意
django 1.10 和之前版本的区别：
在旧版本的 MIDDLEWARE_CLASSES 中，就算一个中间件”短路”了执行过程，所有的中间件都会调用它们的 process_response 方法。而在新的 MIDDLEWARES 版本中，只有这个中间件和在它之前执行的中间件才会调用 process_response 方法。
总结
以上就是 django 在处理一个请求的基本的过程，最后 django 的 WSGI Handler 会创建一个来自 HTTPResponse 的返回值，而且会调用回调函数把数据传递给 web server, 最后返回给用户。
以下是两个关键点：
我们现在知道了视图函数是如何和 url 解析器匹配以及什么在调用它 (WSGI Handler)
有四个关键的地方可以让你挂钩到请求 / 响应周期：process_request, process_response, process_view, process_exception。请求中间件是从外部向内执行，最后抵达到视图函数，然后通过响应中间件从内向外返回。
参考资料
总结
以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，如果有疑问大家可以留言交流，谢谢大家对呐喊教程的支持。
声明：本文内容来源于网络，版权归原作者所有，内容由互联网用户自发贡献自行上传，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任。如果您发现有涉嫌版权的内容，欢迎发送邮件至：notice#nhooo.com（发邮件时，请将#更换为@）进行举报，并提供相关证据，一经查实，本站将立刻删除涉嫌侵权内容。