Django自定义中间件实现请求拦截

本文深入解析了Django 2.0+中自定义中间件的正确实现方式与常见陷阱，涵盖中间件类必须继承MiddlewareMixin、通过__call__方法实现可调用性、在MIDDLEWARE配置中以完整路径注册及执行顺序的关键影响；详解process_request短路机制与process_response的强约束，澄清静态文件不走中间件、404处理差异等易混淆点；同时提供安全修改request/response的实用技巧（如添加响应头、缓存request.body、谨慎处理JSON内容），并直击上线后中间件“静默失效”的根源——WSGI初始化遗漏、settings加载错误、MIDDLEWARE被误写为tuple或环境配置不一致等问题，助你真正掌控请求生命周期中的每一环。

怎么写一个能生效的 Django 中间件类

中间件必须是可调用对象，Django 2.0+ 要求它是个带 __call__ 方法的类，或者返回响应的函数。直接写个普通函数（比如只定义 process_request）在新版里根本不会被调用。

• 必须继承自 django.utils.deprecation.MiddlewareMixin，否则 process_view、process_exception 等方法不会触发
• 类名不重要，但必须在 MIDDLEWARE 配置里完整路径注册，比如 'myapp.middleware.LoggingMiddleware'
• 顺序很关键：靠前的中间件先收到请求、后收到响应；身份校验类要放在日志类前面，否则未登录请求也记了日志

process_request 和 process_response 哪些情况会失效

process_request 在视图执行前运行，但它返回非 None 值时（比如直接返回 HttpResponse），后续中间件和视图就全跳过了；而 process_response 必须接收两个参数 request 和 response，且必须返回 response —— 少一个参数或返回 None 会抛 ValueError: The response middleware didn't return an HttpResponse object。

• 静态文件（DEBUG=True 时由 django.contrib.staticfiles 处理）不经过中间件链，所以想统计 JS/CSS 请求得改用 Nginx 日志
• 404 错误如果由 URL 解析失败引发，process_view 不会执行，但 process_request 和 process_response 仍会走
• 使用 render_to_response（已弃用）或未设 content_type 的响应，可能让某些依赖 header 的中间件出错

如何安全地修改 request 或 response 对象

直接给 request 加属性没问题（比如 request.user_role = 'admin'），但改 response.content 要小心编码和压缩——Gzip 中间件可能已压缩过内容，再 decode-modify-encode 容易破坏格式。

• 想加响应头：用 response['X-Processed-By'] = 'my-middleware'，别碰 response.headers（内部 dict，Django 版本间行为不一致）
• 想读请求体：request.body 只能读一次，后续视图再读就是空字节；需要的话得在 process_request 里缓存，比如 request._cached_body = request.body
• 修改 JSON 响应内容？先判断 response.get('Content-Type', '').startswith('application/json')，再用 json.loads(response.content)，别硬字符串替换

为什么本地调试正常，上线后中间件不执行

最常见原因是 WSGI 入口没传入中间件配置。比如用 Gunicorn 启动时写了 gunicorn myproject.wsgi:application，但 wsgi.py 里漏掉了 django.setup() 或没加载 settings，导致 MIDDLEWARE 是空列表。

• 检查 settings.py 中 MIDDLEWARE 是 list 类型，不是 tuple；Django 会静默忽略 tuple 导致中间件全失效
• 用 python manage.py showmigrations 顺带验证 settings 是否加载成功；如果报错找不到数据库配置，说明中间件环境根本没起来
• 某些部署用 uWSGI --module=mysite.wsgi:application，但 wsgi 文件里写了 os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'mysite.settings.prod')，结果 prod 里注释掉了你的中间件 —— 别信“应该一样”，去服务器上 print(settings.MIDDLEWARE) 看一眼

中间件的执行时机藏在请求生命周期里，不是配上了就万事大吉；尤其是跨环境时，settings 加载路径、WSGI 初始化顺序、甚至 Python 模块搜索路径都可能让它悄无声息地掉队。

到这里，我们也就讲完了《Django自定义中间件实现请求拦截》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！