ORM外键关联需规范声明字段名、on_delete行为（如SET_NULL配null=True）和related_name（如'orders'）；ManyToManyField扩展需自定义中间模型；JOIN性能优化重在索引与精简字段；JSONB动态关联受限于无外键、索引难、JOIN差。
怎么在 ORM 模型里正确声明外键关联
orm 里加关联不是光写个 foreignkey 就完事，关键是字段名、on_delete 行为、反向关系名这三项必须对齐业务逻辑。
常见错误现象：查 User 对应的 Order 时返回空列表，但数据库里明明有数据；或者删用户时报 ProtectedError。
-
on_delete别无脑用CASCADE—— 如果订单要归档保留，该用SET_NULL，且对应字段得加null=True - 反向关系名（
related_name）别留默认值'%(class)s_set'，否则user.order_set.all()这种写法难读又易错，建议显式设成related_name='orders' - 如果关联的是软删除模型（比如带
is_deleted字段），记得在查询时手动加过滤，ORM 不会自动跳过“已删除”记录
Django 中 ManyToManyField 的中间表怎么自定义字段
原生 ManyToManyField 只存 ID 对，一旦需要记录“何时添加”“权重”“状态”等扩展信息，就必须拆成显式的中间模型。
使用场景：用户和标签之间不只是“有/无”关系，还要记打标时间、人工审核状态、置信度分数。
- 去掉原来的
tags = ManyToManyField(Tag)，改用tags = ManyToManyField(Tag, through='UserTag') -
UserTag模型里至少得包含两个ForeignKey：分别指向User和Tag，且联合唯一（unique_together = ('user', 'tag')） - 通过中间模型查数据时，不能直接用
user.tags.all()获取带扩展字段的结果，得走UserTag.objects.filter(user=user).select_related('tag')
SQL 查询里 JOIN 多层关联时性能掉得厉害怎么办
ORM 自动生成的 JOIN 很容易嵌套过深，尤其带 prefetch_related 或 select_related 时，一张表连五层，查询耗时从 20ms 涨到 1.2s 是常态。
根本原因不是 JOIN 本身慢，而是数据库没走索引，或返回了大量冗余字段。
- 检查每层 JOIN 字段是否有索引 —— 特别是外键列和
related_name对应的字段，没索引就加db_index=True - 避免在
select_related里跨多个一对多关系（比如select_related('profile__address__city')），这种链式调用会让 SQL 膨胀极快 - 真要查多层关联数据，优先考虑用原生 SQL 或
values()/values_list()显式指定字段，减少传输和序列化开销
PostgreSQL 中用 JSONB 字段模拟动态关联的边界在哪
有些场景不适合建新表（比如客户自定义字段、临时实验性关联），用 JSONB 存 ID 列表看似灵活，但很快会撞上三个硬限制。
典型错误现象：按某个关联 ID 查记录时，发现无法走索引、没法做外键约束、JOIN 写起来像解谜。
-
JSONB里的 ID 列表不支持数据库级外键，应用层得自己校验引用完整性，漏一次就脏数据 - 想按某个 ID 查所有含它的记录？得用
@> '{"id": 123}'，这种操作 PostgreSQL 无法用普通 B-tree 索引加速，得建 GIN 索引，而且只对整个 JSON 结构有效 - 和其它表
JOIN时，得用jsonb_array_elements()展开，性能差、语法丑、ORM 基本不支持，最后往往退回到应用层双查
真正需要动态结构时，先评估是否能用标准多对多 + 状态字段替代；JSONB 只适合读多写少、不参与复杂关联、且能接受弱一致性的场景。
