Django核心原理与实战案例解析

哈喽！大家好，很高兴又见面了，我是golang学习网的一名作者，今天由我给大家带来一篇《Django核心原理与实战案例详解【指导】》，本文主要会讲到等等知识点，希望大家一起学习进步，也欢迎大家关注、点赞、收藏、转发! 下面就一起来看看吧！

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 TimingMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response
<pre class="brush:python;toolbar:false;">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 环境里跑着 —— 把断点打进去，比读十页源码更管用。

今天关于《Django核心原理与实战案例解析》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！