不能直接用 foreignkey 指向抽象基类，因为抽象基类不生成数据库表，foreignkey 必须关联到具体存在的模型表，否则迁移失败并报 fielderror。
为什么不能直接用 ForeignKey 指向抽象基类
因为 Django 的 ForeignKey 必须指向一个具体存在的模型（即有对应数据表的模型），而抽象基类（abstract = True）不生成表，数据库里根本没有这张表，所以会报 FieldError: Invalid model reference 'xxx'。硬写上去，迁移都跑不过。
常见错误是试图这样写：
class Comment(models.Model):
content_type = models.ForeignKey(ContentType, on_delete=models.CASCADE)
object_id = models.PositiveIntegerField()
content_object = GenericForeignKey('content_type', 'object_id')
# 错误尝试：想让 content_object 只关联到 Article 或 Video
# target = models.ForeignKey('ContentBase', on_delete=models.CASCADE) ← 不行
ContentType + GenericForeignKey 是唯一正解
Django 自带的 ContentType 框架就是为解决这种“跨模型动态关联”设计的，它把每个模型映射成一条记录（app_label + model），再配合 object_id 就能查到任意实例。
实操要点：
-
GenericForeignKey字段本身不存数据，只提供便捷访问；真正存的是content_type（外键到django_content_type表）和object_id（主键值） - 必须在
INSTALLED_APPS里有'django.contrib.contenttypes'，否则ContentType不可用 - 反向查询要用
GenericRelation，不是related_name—— 否则article.comment_set.all()会报错 - 如果目标模型有软删除逻辑（比如带
is_deleted），记得在GenericForeignKey的 getter 里手动过滤
怎么让多态查询更安全、更易用
直接用 content_object 拿到实例后，类型是 Any，IDE 不提示，运行时才可能出错。建议加一层类型检查或封装：
from typing import TYPE_CHECKING
if TYPE_CHECKING:
from myapp.models import Article, Video
<p>class Comment(models.Model):
content_type = models.ForeignKey(ContentType, on_delete=models.CASCADE)
object_id = models.PositiveIntegerField()
content_object = GenericForeignKey('content_type', 'object_id')</p><pre class="brush:python;toolbar:false;">@property
def target(self) -> 'Article | Video | None':
obj = self.content_object
if isinstance(obj, (Article, Video)):
return obj
return None
使用场景举例：
- 后台管理中统一展示所有评论，但需要根据
target类型跳转不同编辑页 → 查content_type.app_label和content_type.model - API 返回评论列表时，要序列化目标对象摘要 → 避免 N+1，用
prefetch_related(Prefetch('content_object', queryset=...))不生效，得用content_type_id__in+ 批量查各模型再合并 - 迁移时若旧数据没清理干净，
content_type记录被删了，content_object会返回None，别假设它一定存在
ForeignKey 替代方案只适用于有限场景
如果子类数量固定且极少（比如就 Article 和 Video 两个），也可以用多个可空 ForeignKey：
class Comment(models.Model):
article = models.ForeignKey('Article', null=True, blank=True, on_delete=models.CASCADE)
video = models.ForeignKey('Video', null=True, blank=True, on_delete=models.CASCADE)
但这会带来明显问题：
- 每新增一类内容就得改模型、加字段、跑迁移
- 数据库里一堆 NULL 列，索引效率低，且无法强制“有且仅有一个非空”（得靠
clean()或数据库 check constraint） - 查所有评论的目标对象时，要写
annotate(target_id=Coalesce('article_id', 'video_id'))这类绕弯逻辑 -
ContentType方案在 admin、rest_framework、graphql 中都有原生支持，这个方案得全自己撸
真遇到性能瓶颈（比如单表几千万评论），才值得考虑分表或物化视图，而不是退回到多 FK —— 那只是把耦合从代码挪到了 schema。
最常被忽略的是：GenericForeignKey 默认不建数据库索引，content_type_id 和 object_id 组合查询慢，上线前一定要加联合索引。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
