优先选 selectinload：它用 in 子查询避免笛卡尔积，适合一对多/多对多；joinedload 仅适用于一对一或主表结果固定且少的场景，否则易致数据冗余。
SQLAlchemy 中 joinedload 和 selectinload 怎么选
预加载不是加个 joinedload 就万事大吉。它会拼 JOIN，一不小心就把主表数据翻倍甚至爆炸——比如查 10 个用户，每人有 5 条订单，joinedload 后结果集变成 50 行，query.all() 返回的还是 10 个用户对象，但底层 SQL 已经拉了冗余数据。
selectinload 更稳：先查主表，再用 IN 批量查关联表，避免笛卡尔积。适合一对多、多对多，尤其当关联数据量大或主表结果不确定时。
- 一对一或主表结果固定且少（如查单个用户详情），
joinedload可以接受 - 一对多且关联项较多（如文章列表带评论数/标签），优先
selectinload -
subqueryload已基本弃用，别碰；lazy='joined'是声明式写法，效果同joinedload，但灵活性差
Django ORM 的 prefetch_related 和 select_related 区别在哪
select_related 走 JOIN，只适用于外键或一对一正向关系；prefetch_related 发额外查询 + Python 层拼接，支持反向关系、多对多、自定义 QuerySet 过滤。
常见翻车点：用 select_related 去查多对多字段，Django 不报错但静默忽略——它根本没法 JOIN 出来，结果就是关联数据为空。
- 查
User.profile（一对一）或Article.author（外键）→ 用select_related - 查
User.posts.all()（反向外键）或Article.tags.all()（多对多）→ 必须用prefetch_related - 需要过滤关联数据？比如“只 prefetch 已发布的文章”，得用
Prefetch对象：prefetch_related(Prefetch('posts', queryset=Post.objects.filter(published=True)))
预加载后 filter 关联字段为啥不生效
很多人写了 select_related('author')，然后加 .filter(author__name='Alice')，以为能筛出 Alice 写的文章——其实可以，但这已经不是“预加载”在起作用了，而是 WHERE 条件下推到了 JOIN 后的 SQL 里。真正的坑在于：如果你本意是“查所有文章，并附带作者信息”，却误加了 filter(author__xxx)，就可能漏掉 author 为 NULL 的文章，或者因 LEFT JOIN 变 INNER JOIN 导致数据丢失。
-
filter在预加载之后执行，影响的是最终结果集，不是预加载行为本身 - 想按关联字段筛选又保留空值？显式用
isnull或Q构造条件，避免隐式 INNER JOIN - Django 中
prefetch_related后不能直接filter关联字段——那是无效的，条件只作用于主表
Go GORM 预加载为什么查不到关联结构体字段
GORM 的 Preload 默认只填充关联字段的 ID（比如 UserID），不会自动把整个 User 结构体查出来，除非你明确告诉它要 Preload 哪个字段。更隐蔽的问题是：如果关联结构体字段名和外键名不一致，或用了 foreignKey / joinForeignKey 自定义，Preload 可能完全找不到对应关系。
- 确保结构体 tag 正确：
type Article struct { UserID uint; User User `gorm:"foreignKey:UserID"` } - Preload 必须写全路径：
db.Preload("User").Find(&articles)，不能写"user"（大小写敏感） - 嵌套预加载如
User.Profile，Profile 结构体也得有正确 tag，且 GORM 版本 ≥ v1.23 才稳定支持多层 - v2 中
Joins("User")类似select_related，但不缓存关联对象，只是临时 JOIN，别和Preload混用
