prefetch_related本身不慢，慢是因未触发预取、误用场景或与select_related冲突；需确保真实访问关联集合、避免values()、正确嵌套序列化器并用debug-toolbar验证SQL。
prefetch_related 本身不慢，慢是因为用错了场景、写错了链路，或者根本没触发预取。
prefetch_related 没触发：模板/序列化器里没真正访问关联集合
它只在你第一次访问 obj.related_set.all()、list(obj.related_set) 或 len(obj.related_set.all()) 时才执行预取查询。如果只是在模板里写了 {{ post.tags }}（默认调用 __str__），或 DRF 序列化器里字段没声明 many=True，预取就白做了。
- 检查是否在视图中调用了
.all()、.count()、list()等触发求值的操作 - Django 模板中避免只写
{{ obj.comments }}，改用{% for c in obj.comments.all %}或显式调用{{ obj.comments.count }} - DRF 中确保
CommentSerializer(many=True)被正确嵌套使用，否则post.comments返回的是 Manager 实例，不触发查询
prefetch_related 和 select_related 混用冲突：同一字段被重复指定
比如你写了 .select_related("author")，又加了 .prefetch_related("author__profile")，Django 会静默忽略后者——因为 author 已经是 JOIN 过来的模型实例，无法再对它的反向关系做 prefetch。
- 遇到深层关联（如
post.author.profile），优先用select_related("author__profile")，而不是拆成select_related("author").prefetch_related("author__profile") - 若
author.profile是OneToOneField，select_related更合适；若是author.posts（反向多对一），才必须用prefetch_related - 用
django.db.connection.queries或django-debug-toolbar看实际发了几条 SQL，确认预取是否生效
values() / values_list() 废掉了所有 prefetch_related
一旦调用 .values("title", "author_id")，QuerySet 返回的是字典或元组，不再是模型实例，后续访问 post.author.name 或 post.tags.all() 会重新触发 N+1 查询。
- 需要字段投影时，改用
.only("title", "author_id")或.defer("content", "body")，它们保留模型实例，不影响预取 - 如果必须用
values()，那就别指望prefetch_related有效，得手动做关联逻辑（比如用dict+groupby在 Python 层拼接） - 注意
annotate()通常不影响预取，但和values()组合时可能改变 QuerySet 类型，需实测验证
最常被忽略的一点：prefetch_related 的“预取”不是魔法，它依赖你明确写出要访问的字段路径，并且在数据使用侧真实触发集合求值。没看到 SQL 减少，先别怀疑 Django，去查 connection.queries —— 很可能那条预取查询压根就没发出去。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
