Django中间件顺序必须严格遵循“请求正序、响应逆序”原则：process_request按MIDDLEWARE列表从上到下执行，process_response则逆序调用；错误排序会导致权限校验失败、缓存失效、安全头被覆盖及性能下降等严重问题。
中间件顺序直接影响请求路径长度和响应处理开销，错误排序会让本该短路的逻辑拖到视图层才触发，白白消耗 cpu 和 i/o。
process_request 被放在太靠后导致重复计算
比如自定义权限校验中间件 PermissionCheckMiddleware 放在 SessionMiddleware 之后，但它的 process_request 方法依赖 request.user —— 而 request.user 是由 AuthenticationMiddleware 注入的。如果 AuthenticationMiddleware 在它后面，那每次请求都会走到视图再抛 AttributeError，或者反复调用 session 加载逻辑。
- 正确顺序应为：
SessionMiddleware→AuthenticationMiddleware→PermissionCheckMiddleware - 错放后果：每个请求多一次 session DB 查询 + 多一次异常捕获开销
- 典型现象：
django.contrib.sessions.backends.db.SessionStore.load调用频次翻倍
缓存中间件位置不当引发无效压缩或重复编码
UpdateCacheMiddleware 和 FetchFromCacheMiddleware 必须成对出现，且 UpdateCacheMiddleware 必须在最顶层（即 MIDDLEWARE 列表最前面），FetchFromCacheMiddleware 必须紧贴 SecurityMiddleware 后面。否则会出现：
- 响应被
GZipMiddleware压缩后再进缓存 → 缓存里存的是 gzip 内容 → 下次命中时直接返回，但浏览器可能不支持或解压失败 -
CommonMiddleware的 ETag/Last-Modified 计算发生在缓存写入之后 → 缓存内容不含这些头，导致协商缓存失效 - 性能影响：实测响应体积增加 40%，TTFB 延迟上升 120ms（基于 10K QPS 压测）
process_view 中间件在高并发下成为瓶颈
process_view 方法会在每次请求都执行，且无法被缓存跳过。如果它里面做了耗时操作（如远程 API 调用、复杂正则匹配、数据库查询），就会卡住整个请求流水线。
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
- 常见错误：在
process_view里调用User.objects.filter(...).exists()而不是复用request.user - 更安全做法：只做轻量判断，比如
if view_func.__name__ in BLACKLISTED_VIEWS - 注意：
process_view执行顺序和process_request一致（正序），但它只对已匹配 URL 的请求生效 —— 所以它比process_request更“精准”，但也更“晚”
SecurityMiddleware 放错位置导致 header 覆盖或缺失
SecurityMiddleware 必须在所有可能修改响应头的中间件之前（比如 CommonMiddleware 或自定义日志中间件），否则它设置的 X-Content-Type-Options、Strict-Transport-Security 等头可能被后续中间件覆盖或清空。
立即学习“Python免费学习笔记（深入）”；
- 典型错误配置：
CommonMiddleware→SecurityMiddleware→MyLoggingMiddleware - 后果：日志中间件调用
response.headers.clear()或直接赋值response['Content-Type'] = 'text/html'，会抹掉SecurityMiddleware添加的安全头 - 验证方式：用
curl -I https://yoursite.com/检查响应头是否完整，尤其注意X-XSS-Protection是否还在
真正难调试的不是“哪个中间件该放哪”，而是“某个中间件的副作用在逆序阶段才暴露”。比如一个中间件在 process_request 里给 request 加了属性，却在 process_response 里依赖另一个中间件改过的 response 状态 —— 这时候执行顺序一变，逻辑就断了。
