24-Django请求全链路-WSGI到数据库响应的完整旅程

一个请求从浏览器到数据库的完整旅程——Django 全链路拆解

📖 文章简介： 你点了浏览器的"刷新"按钮，0.5 秒后页面渲染完毕。这 0.5 秒里发生了什么？本文把 Django 处理一个 HTTP 请求的完整链路拆为六个步骤：WSGI Server 接收 TCP 连接 → 中间件栈的洋葱模型逐层处理 → URL 路由匹配 → View 执行业务逻辑 → ORM 生成 SQL 并发送到数据库 → Template 渲染或 JSON 序列化返回响应。每一步都配有对应的源码位置和关键代码片段，读完你能对一个请求的全生命周期建立起清晰的空间模型。穿插真实调试经历——一个中间件错误导致所有 API 请求多耗 200ms 的排查过程。

🎬 个人主页： 源码骑士

❄ 专栏传送门： 《Android开发基础》《python基础课程》

⭐️热衷从源码视角拆解技术底层原理，将复杂架构讲得通俗易懂

🎬 源码骑士的简介：
5年Android Framework系统开发经验，曾主导多项系统级性能优化专项
技术栈覆盖Android系统全链路（Binder/Handler/AMS/WMS/启动流程）及Java后端全家桶（Spring + MyBatis + Redis + Oracle）
累计产出原创技术文章100+篇，文章以源码拆解为特色，被读者评价为"看一篇胜过啃一周文档"

导入语

2022 年，我排查过一个有趣的性能问题。系统所有 API 接口的响应时间长了约 200ms，但 DBA 说数据库正常、运维说网络正常。最后发现是一个中间件里有一段同步调用外部服务（获取当前用户权限），阻塞 200ms——而这 200ms 在 每个请求里都要重复一遍。

这个排查过程让我意识到——如果不把"一个请求走过的每一步"连成一条完整的链路，你很难单独定位每一步在哪出了问题。本文拆解 Django 请求的全链路——从浏览器发出到数据库返回，六个步骤步步相连。

1 ~> 整体链路图——一步到位

浏览器                WSGI Server          Django          数据库
  │                      │                  │               │
  ├─① HTTP Request ─────→│                  │               │
  │                      ├─② 解析为 environ │               │
  │                      ├─③ get_response()─→│              │
  │                      │                  ├─④ 中间件链     │
  │                      │                  ├─⑤ URL 路由    │
  │                      │                  ├─⑥ View 执行   │
  │                      │                  ├─⑦ ORM ───────→│
  │                      │                  │←──── ⑧ 结果 ──┤
  │                      │                  ├─⑨ 渲染/序列化  │
  │                      │←─⑩ HTTP Response─┤              │
  │←──── ⑪ 响应 ─────────┤                  │               │

2 ~> 第一步：WSGI Server——TCP 连接变 Python 字典

浏览器发出 HTTP 请求后，由 WSGI Server（Gunicorn / uWSGI / Django 自带 runserver）接收 TCP 数据。WSGI Server 把 HTTP 请求解析成一个 Python 字典——environ：

environ = {
    "REQUEST_METHOD": "GET",
    "PATH_INFO": "/api/v1/users/",
    "QUERY_STRING": "page=2",
    "HTTP_HOST": "example.com",
    "HTTP_AUTHORIZATION": "Bearer xxx",
    "wsgi.input": ...,  # 请求体流
}

然后调用 application(environ, start_response)——这是 WSGI 协议的核心。Django 中的入口是这个函数：

# django/core/handlers/wsgi.py
class WSGIHandler(base.BaseHandler):
    def __call__(self, environ, start_response):
        request = self.request_class(environ)  # 把 environ 包装成 HttpRequest
        response = self.get_response(request)  # ← 核心入口

从这行起开始，请求进入 Django 核心。

3 ~> 第二步：中间件链——洋葱模型

# django/core/handlers/base.py
def get_response(self, request):
    # 把中间件列表从外到内包装
    handler = self._get_response             # 核心处理函数
    for middleware in reversed(self._middleware_chain):
        handler = middleware(handler)        # 每个中间件包裹内层
    return handler(request)

中间件链的执行顺序是洋葱模型：

请求进 → 中间件1(前) → 中间件2(前) → 中间件3(前) → View
                                                    ↓
响应出 ← 中间件1(后) ← 中间件2(后) ← 中间件3(后) ←──┘

一个典型的自定义中间件结构：

class TimingMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        # 前置处理
        start = time.time()

        response = self.get_response(request)   # 调用内层（可能是下一个中间件或 View）

        # 后置处理
        duration = time.time() - start
        response["X-Request-Duration"] = str(duration)
        return response

4 ~> 第三步到第六步：路由 → View → ORM → 响应

4.1 URL 路由匹配

# django/urls/resolvers.py
resolver = get_resolver()
match = resolver.resolve(request.path_info)
# match.func → View 函数或 View 类
# match.kwargs → URL 中捕获的参数 {pk: 42}

4.2 View 执行

View 从请求中提取参数，调业务逻辑。典型的 FBV：

def user_list(request):
    users = User.objects.select_related("department").all()
    return render(request, "users.html", {"users": users})

4.3 ORM 生成 SQL

Django ORM 的 QuerySet 在被迭代或切片时触发实际的数据库查询：

# 还没查数据库——QuerySet 是惰性的
users = User.objects.filter(active=True)

# 现在才查——QuerySet 被 list() 或 for 循环迭代
for user in users:   # ← 这里才执行 SQL
    print(user.name)

4.4 响应返回

Django 把响应包装为 HttpResponse 对象。WSGI Server 取出 response.content 和 response.status_code，按 HTTP 协议发回浏览器。从 WSGI 入口到出口，一个请求在 Django 内部走完全链路。

5 ~> 排查中间件性能问题——真实案例

2022 年的那个问题。所有接口慢了 200ms：

class PermissionMiddleware:
    def __call__(self, request):
        # 每个请求都调外部权限服务
        resp = requests.get(f"http://auth-service/check?user={request.user.id}")
        request.permissions = resp.json()
        return self.get_response(request)

外部 Auth 服务响应 200ms。每个请求——不管是静态文件还是 API 调用——都要经过中间件的权限检查。即使用户已经缓存了，中间件每次都调一次外部服务。

优化方案： 权限查询结果缓存到 Redis，缓存周期 5 分钟。200ms 降到大约 0.5ms。

思考 && 总结

Django 请求全链路六个步骤：

1. WSGI Server 把 HTTP 请求包装为 environ 字典
2. 中间件链 以洋葱模型从外到内层层处理，再从内到外层层返回
3. URL 路由 按 urlpatterns 顺序匹配 → 找到对应的 View
4. View 解析请求参数 → 调用业务逻辑
5. ORM 惰性生成 SQL → 向数据库发起查询
6. 响应 经过中间件链反向输出 → 返回浏览器

结尾

请求全链路拆解完毕，感谢阅读！

源码骑士 — 源码级拆解，从底层看透技术

👀 关注：跟博主一起从源码视角深耕底层原理

❤️ 点赞：让优质内容被更多人看见

⭐ 收藏：核心知识点存好，随用随查

💬 评论：分享你的经验或疑问，一起交流

🔄 一键四连：别忘了给博主一键四连！

🗡️ 寄语：把请求走过的路走一遍，才知每一步哪里可能出问题。

结语：Django 请求的六个步骤是你排查所有性能问题的基准线。下篇讲数据库连接池——它不是为了让连接更快。一键四连！