文章目录
- 一个请求从浏览器到数据库的完整旅程——Django 全链路拆解
-
- 导入语
- 1 ~> 整体链路图——一步到位
- 2 ~> 第一步：WSGI Server——TCP 连接变 Python 字典
- 3 ~> 第二步：中间件链——洋葱模型
- 4 ~> 第三步到第六步：路由 → View → ORM → 响应
-
- 4.1 URL 路由匹配
- 4.2 View 执行
- 4.3 ORM 生成 SQL
- 4.4 响应返回
- 5 ~> 排查中间件性能问题——真实案例
- 思考 && 总结
- 结尾
一个请求从浏览器到数据库的完整旅程——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 请求全链路六个步骤：
结尾
请求全链路拆解完毕，感谢阅读！
源码骑士 — 源码级拆解，从底层看透技术
👀 关注：跟博主一起从源码视角深耕底层原理
❤️ 点赞：让优质内容被更多人看见
⭐ 收藏：核心知识点存好，随用随查
💬 评论：分享你的经验或疑问，一起交流
🔄 一键四连：别忘了给博主一键四连！
🗡️ 寄语：把请求走过的路走一遍，才知每一步哪里可能出问题。
结语：Django 请求的六个步骤是你排查所有性能问题的基准线。下篇讲数据库连接池——它不是为了让连接更快。一键四连！
