8、djangop中间件： 中间件顾名思义，是介于request与response处理之间的一道处理过程，相对比较轻量级，并且在全局上改变django的输入与输出。 因为改变的是全局，所以需要谨慎实用，用不好会影响到性能。我们从浏览器发出一个请求 Request，得到一个响应后的内容 HttpResponse ，每一个请求都是先通过中间件中的 process_request 函数，这个函数返回 None 或者 HttpResponse 对象， 如果返回前者，继续处理其它中间件，如果返回一个 HttpResponse，就处理中止，返回到网页上。中间件不用继承自任何类 （可以继承 object ） 中间件的用处： 比如我们要做一个 拦截器，发现有恶意访问网站的人，就拦截他！假如我们通过一种技术，比如统计一分钟访问页面的次数， 太多就把他的 IP 加入到黑名单 用法： 我们在网站放到服务器上正式运行后，DEBUG改为了 False，这样更安全，但是有时候发生错误我们不能看到错误详情，调试不方便， 有没有办法处理好这两个事情呢？普通访问者看到的是友好的报错信息；管理员看到的是错误详情，以便于修复 BUG；当然可以有， 利用中间件就可以做到，个Django项目的起始执行如下：先走WSGI，然后再走中间件，注意一点，自带的中间件的顺序是不能倒置的， 因为有可能下一个中间件要依赖于上一个中间件的数据，如果随意颠倒顺序，会报错，我们通常将自定义的中间件放到最下面 request请求经过WSGI后，先进入中间件，依然开始先走process_request函数，然后走路由关系映射后，这里注意 并没有直接进入视图函数，而是从头开始执行process_view()函数；然后再去执行与urls.py匹配的视图函数； 如果视图函数没有报错，那就直接挨个反过来从最后一个中间件开始，依次将返回的实例对象(也就是我们在视图函数中 写的 return HttpResponse()等等)传递给每个中间件的process_response函数；最后再交给客户端浏览器； 如果执行视图函数出错，那就反过来从最后一个中间件开始，将错误信息传递给每个中间件的process_exception()函数，走完所有后， 然后最终再走procss_response后，最终再交给客户端浏览器 注意：视图函数的错误是由process_exception()函数处理的，从最后一个中间件开始，依次逐级提交捕捉到的异常