django中间件系统 - 请求处理的拦截器模式
📂 所属阶段:第二部分 — 进阶特性
🎯 难度等级:中级
⏰ 预计学习时间:3-4小时
🎒 前置知识:视图系统与URL路由
目录
中间件概念与核心结构
django中间件是全局请求/响应拦截器框架——类似给请求流加了「安检站」和「收尾台」,能在不修改视图/模板的前提下,给整个应用加功能。
最简单的中间件长这样
从django 1.10开始,新风格中间件是主流,只需实现两个核心方法:
中间件执行流程与配置
洋葱模型:核心执行逻辑
中间件的执行是「洋葱结构」——配置列表靠前的先拦请求,后拦响应:
必须在 settings.py 注册
自定义中间件不注册=没用,推荐放在列表最后,避免破坏内置中间件的依赖关系:
高频内置中间件速览
django默认带了10+内置中间件,不用全学,重点掌握这5个:
1. SecurityMiddleware(安全拦截第一站)
自动加HTTPS、HSTS、XSS防护等安全头,生产环境必须保留。
2. SessionMiddleware(会话管理)
给每个请求/响应加sessionidCookie,关联服务端的会话数据,必须放在AuthenticationMiddleware前面。
3. CsrfViewMiddleware(防跨站伪造)
检查POST/PUT/PATCH请求的CSRF令牌,防止恶意网站盗用用户身份。
4. AuthenticationMiddleware(身份注入)
从会话中提取用户信息,注入到request.user(已认证是User对象,未认证是AnonymousUser)。
5. CommonMiddleware(通用功能)
自动处理URL尾部斜杠、APPEND_SLASH配置,生产环境建议保留。
自定义中间件实战
选两个开发中100%会用到的场景:
1. 慢请求/异常日志中间件
记录每个请求的耗时、状态码、IP,便于排查问题:
2. 简易接口限流中间件
防止恶意刷接口(简单版,生产环境推荐用django-ratelimit库):
执行顺序与最佳实践
顺序红线(踩了必出问题)
- SessionMiddleware → AuthenticationMiddleware:认证依赖会话
- SecurityMiddleware → 所有其他中间件:安全第一
- CommonMiddleware → CsrfViewMiddleware:通用处理依赖URL标准化
性能与安全最佳实践
- 初始化只做1次:
__init__里加载静态资源、编译正则,不要在__call__里查全表 - 快速返回:用正则或前缀判断提前拦截不需要处理的请求(如静态文件)
- 不要吞异常:除非有明确的处理逻辑,否则用
logger.error后继续抛出 - 自定义中间件放最后:避免破坏内置中间件的依赖链
常见坑点排查
坑1:自定义中间件没生效
- 排查1:检查
MIDDLEWARE列表的路径是否正确(注意.分隔,不是/) - 排查2:检查中间件类是否有
__init__(self, get_response)和__call__(self, request)方法 - 排查3:检查是否有语法错误(启动django会报错)
坑2:CSRF验证失败
- 排查1:检查表单/请求是否带了
{% csrf_token %}或X-CSRFToken请求头 - 排查2:检查反向代理是否把
HTTP_X_CSRFTOKEN透传给django - 排查3:检查
CSRF_TRUSTED_ORIGINS是否包含前端域名(生产环境必须HTTPS)
坑3:request.user是AnonymousUser
- 排查1:检查
SessionMiddleware是否在AuthenticationMiddleware前面 - 排查2:检查会话是否过期(
SESSION_COOKIE_AGE) - 排查3:检查是否通过
login()方法登录了
本章小结
本章我们掌握了django中间件的核心知识:
- 概念:全局请求/响应拦截器,类似洋葱模型
- 结构:新风格只需
__init__和__call__,旧风格用MiddlewareMixin - 内置中间件:重点学Security、Session、Csrf、Authentication、Common
- 实战:写了日志和限流两个常用中间件
- 坑点:顺序不对、路径错误、CSRF配置问题
💡 核心提醒:中间件是「双刃剑」——能快速加全局功能,但加太多会拖慢请求!尽量只加必要的。
🔗 相关教程
🏷️ 标签:django中间件 请求处理 拦截器 自定义中间件 django安全

