该用 defer() 和 only() 的时机是：当模型字段多但视图仅需少数字段（如列表页只用标题和创建时间），且明确知道某些字段本次请求中完全不会被访问（defer）或只需特定字段（only）。
什么时候该用 defer() 和 only()
当你的模型有十几个字段，但视图里只读取其中两三个（比如展示列表页只显示标题和创建时间），却调用 Model.objects.all() 时，数据库会把整行所有字段都查出来——哪怕你根本没用到 description 或 content_html 这种大文本字段。这时候就该上 defer() 或 only()。
核心判断标准：是否在循环中反复访问对象的某些字段；是否在模板或序列化时明确知道只需要部分字段。
-
defer('field1', 'field2')：告诉 Django “先别查这些字段”，等真用到时再触发一次懒加载（SELECT + WHERE） -
only('field1', 'field2')：只查指定字段，其他全不碰——连 ORM 层的字段属性都不可用（访问会报FieldError） - 两者不能同时用；
only()的优先级高于defer()，混用时后者会被忽略
defer() 的坑：看似省了查询，实际可能更慢
很多人以为 defer 就是“少查几个字段=更快”，但真实情况常相反。因为 defer() 不是过滤 SELECT 列表，而是把字段标记为“延迟加载”，一旦你在模板里写了 {{ obj.description }}，Django 就会为这个对象单独发一条 SQL 去补查——对 100 条记录就是 100 次额外查询。
- 只有当你确定某字段在本次请求中「完全不会被访问」时，
defer()才安全 - 常见误用：在 ListView 中
defer('content')，结果模板里又写了{{ article.content|truncatewords:20 }}——立刻触发 N+1 - 关联字段如
author__avatar也能 defer，但要注意外键本身是否已 select_related；否则 defer 后再访问仍会触发 JOIN 查询
only() 更可控，但得小心字段缺失报错
only() 是真正减少 SELECT 字段数的方式，生成的 SQL 里只会包含你列出的字段。它适合字段明确、逻辑封闭的场景，比如后台导出 CSV 或 API 返回精简数据。
立即学习“Python免费学习笔记（深入）”；
- 未被
only()包含的字段，在 Python 层访问会直接抛django.core.exceptions.FieldError: Cannot resolve keyword 'xxx' into field - 主键（
id）总是会被自动包含，即使你没写进only()参数里 - 外键字段（如
category_id）可以only()，但反向关系（article_set）或category.name这类需要 JOIN 的访问依然会失败，除非配合select_related() - 示例：
Article.objects.only('title', 'pub_date').select_related('author')是合理组合；但only('title').select_related('author')会导致 author 字段查不到（因 author_id 被排除）
比 defer/only 更值得优先考虑的优化点
很多团队一上来就折腾 defer()，其实 80% 的性能问题出在更基础的地方：没做 select_related() / prefetch_related()，或者在 for 循环里反复查数据库。相比字段级优化，关联查询优化收益高得多，且不易踩坑。
- 先用
django-debug-toolbar看 SQL 数量和单条耗时，确认瓶颈真在字段冗余，而不是 N+1 - 大文本字段（
TextField、JSONField）建议默认db_column分离到另一张表，而不是靠defer()补救 - 如果只是 API 序列化需要精简字段，用
Serializer的fields或exclude控制输出更安全，不干扰 ORM 查询逻辑
字段级懒加载听着聪明，实操中很容易变成“用一个 bug 挡另一个 bug”。真要压榨查询效率，先盯死 JOIN 和 N+1，再动 defer() 和 only()。
