select_related 和 prefetch_related 不能混用同一外键字段，因为前者通过 JOIN 提前加载，后者会被静默忽略；例如 Book.objects.select_related('author').prefetch_related('author__books') 中 author__books 不执行。
为什么 select_related 和 prefetch_related 不能混用同一个外键字段
当你在 Django 5.0 中对同一外键字段既调用 select_related 又调用 prefetch_related，Django 不会报错，但后者会被静默忽略——因为 select_related 已通过 JOIN 提前加载了该关系，prefetch_related 的额外查询根本不会触发。这容易让你误以为“双重保险”更安全，实际只是浪费了一次无意义的链式调用。
典型错误写法：
Book.objects.select_related('author').prefetch_related('author__books')这里 author 已被 JOIN 加载，author__books 的 prefetch 实际不执行。
- 一对一或外键正向关系（如
Book.author）优先用select_related - 多对多、反向 ForeignKey（如
Author.books_set）必须用prefetch_related - 若需同时优化正向 + 反向，分开处理：先
select_related('author')，再prefetch_related('author__books')—— 注意是author__books，不是重复author
使用 only() 和 defer() 时，哪些字段操作会触发完整模型加载
only() 和 defer() 看似简单，但只要访问到未包含的字段，Django 就会立刻发起一次额外的 SELECT 查询（哪怕只读一个属性），且这个查询会拉取整行所有字段——完全抵消优化效果。
例如：
book = Book.objects.only('title', 'isbn').get(id=1)<br>print(book.title) # ✅ 安全<br>print(book.author.name) # ❌ 触发新查询（因 author 是外键，未在 only 中显式声明）<br>print(book.description) # ❌ description 未包含，触发全字段查询
立即学习“Python免费学习笔记（深入）”；
提供使用 django-unfold (v0.56+) 构建高级 Django 管理界面的专业指导。当用户提及 django-unfold、unfold admin 等内容时使用此技能。
-
only()后，仅能安全访问列出的字段；连_state、pk这类隐式属性都可能触发重查（取决于是否在列表中） -
defer('description')并不阻止你读description，但第一次读就会查全字段——无法“按需懒加载单个字段” - Django 5.0 对 JSONField、TextField 等大字段做
defer()效果明显，但对 CharField 等小字段收益有限，反而增加逻辑复杂度
如何判断 values() / values_list() 返回结果是否还能调用模型方法
调用 values() 或 values_list() 后，返回的是 ValuesQuerySet（Django 5.0 中为 ValuesQuerySet 的子类），它不再包含模型实例，而是字典或元组。这意味着你不能再调用任何模型定义的方法（比如 get_absolute_url()）、不能访问 ManyToManyField 关系、也不能使用 save()。
常见误判场景：
books = Book.objects.values('title', 'author_id')<br>for b in books:<br> print(b['title']) # ✅<br> print(b.author.get_name()) # ❌ AttributeError: 'dict' object has no attribute 'author'
-
values_list('title', flat=True)返回QuerySet[str]，适合做集合去重或简单迭代，但失去所有模型上下文 - 如果需要部分字段 + 模型能力，改用
only()+select_related()组合更稳妥 -
values()在聚合、导出、前端渲染等只读场景高效；一旦涉及业务逻辑或关联计算，退回模型实例更安全
Django 5.0 中 annotate() 配合 Count() 时，distinct=True 的必要性
当 annotate(Count('related_model')) 出现重复计数（比如一对多 JOIN 导致主表行膨胀），默认结果会虚高。Django 5.0 要求你显式指定 Count('related_model', distinct=True) 来修正——不加 distinct=True 不是“默认去重”，而是默认不做去重。
例如统计每位作者出版的书数：
# 错误：若 Author 有多个 Tag 关联，会导致 book 计数翻倍<br>Author.objects.annotate(book_count=Count('books'))<br><br># 正确：明确去重<br>Author.objects.annotate(book_count=Count('books', distinct=True))
-
distinct=True在 PostgreSQL 上生成COUNT(DISTINCT ...)，在 SQLite 上通过子查询模拟，MySQL 8.0+ 支持原生语法 - 若关联路径含多层（如
'books__tags'），distinct=True仍有效，但性能下降明显，此时应考虑预聚合或物化视图 - 不要依赖数据库方言自动推断去重逻辑；Django 5.0 不再为 Count 隐式添加 distinct，这是行为变更点
Django 5.0 的查询优化没变魔术，它只是把旧版里模糊的默认行为（比如某些隐式 distinct）收得更紧了。最常被忽略的是：字段访问触发重查的时机、annotate 的 distinct 必须显式声明、以及 values() 后彻底脱离模型生命周期——这些不是“高级技巧”，而是日常写 query 时每行都要检查的硬约束。
