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</pre>
QuerySet 延迟执行到底延迟到哪一步？
不是“调用 filter() 就查库”，也不是“模板里用才查”，而是直到真正需要数据时才触发 SQL —— 但这个“需要”有明确边界。
立即学习“Python免费学习笔记（深入）”；
- 迭代
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 环境里跑着 —— 把断点打进去，比读十页源码更管用。
