Django请求生命周期调试：接收请求后首个执行函数及断点位置咨询

接收请求后的第一个核心函数 #

当Django通过WSGI接口接收到请求时，第一个被调用的核心函数是django.core.handlers.wsgi.WSGIHandler.__call__()。这是Django和WSGI服务器（比如默认的wsgiref或者生产环境的Gunicorn）对接的入口点，所有HTTP请求都会先流经这里。

这个方法的核心逻辑大概是：

• 首次请求时调用self.load_middleware()加载所有配置的中间件
• 将原始WSGI环境变量封装成HttpRequest对象
• 调用self.get_response(request)触发后续的中间件处理和视图执行流程

插入断点观察中间件处理过程的最佳位置 #

如果你想完整追踪中间件的process_request、process_view等方法的执行顺序，这几个关键位置很适合插断点：

1. WSGIHandler.__call__（最上游入口） #

在这个方法里插断点，你能看到请求刚进入Django时的原始状态——包括WSGI环境变量如何被转换为HttpRequest对象，以及中间件加载的初始化过程，相当于从请求处理的“源头”开始追踪。

2. BaseHandler.get_response（中间件执行的核心调度点） #

这个方法是Django处理请求的核心调度器，里面会按顺序执行：

• 所有中间件的process_request方法（严格遵循你在settings.py里配置的顺序）
• 匹配URL路由找到对应的视图函数
• 所有中间件的process_view方法
• 执行目标视图函数
• 处理视图返回的响应，依次执行中间件的process_response方法

你可以在这个方法里找到遍历self._request_middleware的循环处插断点，这里就是逐个调用中间件process_request的地方，能清晰看到每一步的执行顺序和参数传递。

3. 自定义中间件的process_request（快速定位业务逻辑） #

如果你只关注自己项目中配置的中间件执行，可以直接在你写的第一个中间件的process_request方法里插断点，这样能快速进入你的业务逻辑调试，但看不到Django内置中间件的执行过程。

举个pdb调试的小例子 #

如果用命令行调试，你可以直接在Django源码里临时插入断点：

# 打开django/core/handlers/wsgi.py，在WSGIHandler.__call__方法开头添加
import pdb; pdb.set_trace()

然后运行python manage.py runserver，当你访问localhost:8000/test时，程序会在这里暂停，你可以用n（下一步）、s（进入函数）等命令逐步追踪后续的中间件调用流程。

内容的提问来源于stack exchange，提问作者Anton Frolov