django中间件按middleware配置顺序执行：请求阶段从上到下调用__call__()/process_request()，视图前调用process_view()，响应阶段从下到上执行process_response()，异常时逆序触发process_exception()。
当一个HTTP请求到达Django应用时，它会依次经过一系列标准化处理环节，中间件（Middleware）正是贯穿整个请求响应流程的核心钩子机制。理解它的执行顺序和作用时机，是调试性能、实现权限控制、日志记录或请求预处理的关键。
请求进入：从WSGI到中间件链的前置处理
Django接收到请求后，首先由WSGI服务器（如Gunicorn）封装为HttpRequest对象，然后按MIDDLEWARE配置列表**从上到下**依次调用每个中间件的process_request()（已弃用）或更通用的__call__()方法（新式类中间件）或process_view()等钩子。例如，SecurityMiddleware会在早期检查HTTP头安全性，SessionMiddleware则立即尝试从cookie加载session数据并绑定到request.session。
- 每个中间件可选择直接返回
HttpResponse（如登录校验失败时重定向），中断后续流程 - 若未返回响应，请求继续向视图函数/类传递
- 中间件内部可修改
request对象（如添加属性、解析JSON body）
视图执行：中间件在路由与业务逻辑之间的桥梁
请求抵达匹配的视图前，Django会调用所有中间件的process_view()方法（如果定义）。这个阶段适合做细粒度权限判断（比如检查用户是否有访问该视图的权限）、参数预处理（如统一解析签名参数）或请求审计（记录目标视图名与参数）。注意：process_view只对成功匹配URL的视图生效，404或异常情况不会触发。
- 该方法接收
request、视图函数、*args、**kwargs，可返回None（继续）或HttpResponse（短路） - 多个中间件的
process_view按MIDDLEWARE顺序执行，但返回响应时仅生效第一个
响应生成：中间件对输出内容的最后干预机会
视图返回HttpResponse后，Django将响应对象沿中间件链**从下到上**反向传递，依次调用各中间件的process_response()方法。这是修改响应头（如添加CORS头、缓存策略）、压缩内容（GZipMiddleware）、记录响应耗时或脱敏敏感字段的理想位置。
- 每个
process_response必须返回HttpResponse对象（可原样返回或替换） - 即使视图抛出异常，只要中间件实现了
process_exception()，也会在响应阶段前被调用（同样逆序） -
process_template_response()仅在响应对象有render()方法时触发（如TemplateResponse），用于模板上下文增强
异常处理：中间件如何捕获并转化错误流
当视图或前置中间件抛出未捕获异常时，Django会从最内层（即MIDDLEWARE列表末尾）开始，逆序调用各中间件的process_exception(request, exception)。典型用途包括：将ValidationError转为400 JSON响应、捕获PermissionDenied并渲染自定义403页面、或统一上报错误日志。
- 该方法不需返回值；若某个中间件处理了异常（如返回了HttpResponse），后续中间件的
process_exception将不再调用 - 若所有中间件都未处理，Django进入默认异常响应流程（调试模式显示Traceback，生产环境返回500）
