PythonDjango系统学习路线第267讲_核心原理与实战案例详解【指导】

Django核心原理需在真实请求生命周期中验证：中间件顺序决定执行时序，QuerySet延迟至真正需要数据时求值，select_related仅对正向外键有效，as_view()返回绑定参数的闭包函数。

这门课不是用来“学完就扔”的速成课，Django 的核心原理必须在真实请求生命周期里反复验证，否则看十遍 get_response 流程图也写不出能扛住并发的中间件。

为什么你改了 `MIDDLEWARE` 顺序却没生效？

常见现象：加了一个记录耗时的中间件，但 process_view 里拿不到 request.user；或者 process_exception 根本不触发。

根本原因在于 Django 请求处理链是单向、不可跳过的线性栈，中间件执行顺序严格由 MIDDLEWARE 列表从上到下决定，且每个钩子（process_request、process_view 等）只在特定阶段存在。

process_request 在 URL 解析前执行，此时 request.user 还没被 AuthenticationMiddleware 注入
若把自定义中间件放在 AuthenticationMiddleware 之前，request.user 就是 AnonymousUser
process_exception 只对视图函数抛出的异常生效，对 process_request 中的异常无效

class TimingMi

ddleware: def __init__(self, get_response): self.get_response = get_response

def __call__(self, request):
    start = time.time()
    response = self.get_response(request)  # ← 必须放这里，才能覆盖整个周期
    duration = time.time() - start
    logger.info(f"{request.path} took {duration:.3f}s")
    return response

`QuerySet` 延迟执行到底延迟到哪一步？

不是“调用 filter() 就查库”，也不是“模板里用才查”，而是直到真正需要数据时才触发 SQL —— 但这个“需要”有明确边界。

迭代 QuerySet（如 for obj in qs:）、转 list(qs)、切片（qs[:5]）、调用 bool(qs) 或 len(qs) 都会强制求值
qs.filter(...).order_by(...) 这类链式调用永远不查库，只是叠加查询条件
模板中 {% for item in object_list %} 是典型的隐式求值点，也是 N+1 查询高发场景

容易踩的坑：在视图里写 qs = MyModel.objects.filter(...)，然后在模板里反复用 qs.count 和 qs.first —— 这会触发两次查询，因为 count() 走 COUNT(*)，而 first() 走 SELECT ... LIMIT 1，两者无法复用结果。

如何让 `select_related` 真正生效？

select_related 只对外键（ForeignKey）和一对一（OneToOneField）有效，且必须在查询时显式声明关联字段，否则 ORM 不会自动拼 JOIN。

错误写法：Book.objects.all() 然后模板里写 {{ book.author.name }} → 触发 N+1
正确写法：Book.objects.select_related('author') → 一条 JOIN 查出所有字段
多层关联要写全路径：select_related('author__profile')，不能只写 'author' 就指望 profile 也被预取
对反向外键（ForeignKey 反向）或 ManyToManyField，必须用 prefetch_related，select_related 完全无效

`as_view()` 返回的到底是什么？

不是函数，也不是类实例，而是一个闭包函数 —— 它绑定了类、HTTP 方法映射、以及初始化参数（如 template_name），每次请求都新建一个 view 实例。

这意味着：

类属性（如 queryset = MyModel.objects.all()）在模块加载时就执行一次，所有请求共享同一个 QuerySet 对象（注意：不是共享结果，而是共享查询定义）
实例属性（如 self.object_list）在每次请求的 dispatch() 中才生成，彼此隔离
如果你在 get() 里修改了 self.queryset，它不会影响其他请求，但会影响本次请求后续的 get_queryset() 调用

这也是为什么基于类的视图（CBV）比函数视图（FBV）更难调试：执行流分散在多个方法中，而关键状态（如 self.kwargs、self.request）只在实例生命周期内存在。

Django 的“约定大于配置”背后全是显式可追踪的 Python 代码，别信文档里轻描淡写的“自动”，每个 get_queryset、每个 dispatch、每个 resolve 调用，都在你装好的 Python 环境里跑着 —— 把断点打进去，比读十页源码更管用。

# python # go # 栈 # django # 为什么

返回目录在线咨询

上一篇：VPS支持下的在线教育平台：课程销售与订阅服务盈利之道
下一篇：AngularJS ng-repeat指令中使用track by子语句解决重复数据遍历错误问题

您的项目需求

*请认真填写需求信息，我们会在24小时内与您取得联系。

全网整合营销服务商

PythonDjango系统学习路线第267讲_核心原理与实战案例详解【指导】

为什么你改了 MIDDLEWARE 顺序却没生效？

QuerySet 延迟执行到底延迟到哪一步？

如何让 select_related 真正生效？

as_view() 返回的到底是什么？

您的项目需求

为什么你改了 `MIDDLEWARE` 顺序却没生效？

`QuerySet` 延迟执行到底延迟到哪一步？

如何让 `select_related` 真正生效？

`as_view()` 返回的到底是什么？