Preload("A.B.C") 生成3条SQL，即主表1次、每级关联各1次；采用分层批量查询而非JOIN，避免笛卡尔积和解析错误，通过ID提取+IN查询+内存组装实现准确嵌套挂载。
Preload("A.B.C") 生成几条 SQL？
不是一条，也不是简单按层级叠加；GORM v1.9.11+ 对 Preload("A.B.C") 的处理是「分层批量查询」：主表查 1 次，每级关联查 1 次，共 3 条独立 SQL。例如 Preload("Games.Players") 会执行：
SELECT * FROM rooms WHERE id = ?SELECT * FROM games WHERE room_id IN (?)SELECT * FROM players WHERE game_id IN (?)
它不会用 JOIN 拼成单条语句，也不把三级数据塞进一个结果集。这是因为 GORM 的预加载本质是「ID 提取 + 批量 IN 查询 + 内存组装」，避免 JOIN 导致的笛卡尔爆炸和重复行解析开销。
为什么不能用 Joins 替代多级 Preload？
Joins 在多级嵌套时极易出错，尤其当某级是一对多（如 Room → Games）且下一级也是一对多（Games → Players）时，LEFT JOIN 会产生指数级膨胀的数据行。比如 1 个 Room、3 个 Games、每个 Game 各有 5 个 Players，JOIN 结果就是 1 × 3 × 5 = 15 行，GORM 默认无法正确还原三层结构——Players 字段会被覆盖或丢失。
而 Preload 分离查询后，在内存中按外键关系逐层挂载，能准确构建 []*Game 和每个 Game.Players 的切片。除非你明确需要单次网络往返且数据量极小，否则别用 Joins("Games").Joins("Players") 去模拟三级加载。
嵌套字段名大小写和标签必须完全匹配
GORM 反射解析 Preload("Games.Players") 时，会严格比对结构体字段名，而不是数据库列名或 tag 中的 column。常见翻车点：
- 结构体定义
Games []Game，但 preload 写成Preload("games.Players")（小写 g）→ 报错can't find field games in main.Room -
Players字段没加gorm:"foreignKey:GameID"，GORM 无法推导外键 → 第二层查询无条件，返回空切片 - 嵌套结构中某级是
*Player而非[]Player，但数据库是一对多 → 字段类型不匹配，预加载静默失败
务必确认：所有中间字段都是导出的（首字母大写），路径中每一级都对应真实字段名，且外键声明完整。
深度嵌套时性能瓶颈不在 SQL 次数，而在内存组装
从 Preload("A.B.C.D.E") 到 5 级，SQL 还是 5 条，但 GORM 需在内存中做 4 轮嵌套挂载：先按 A.ID 绑定 B，再按 B.ID 绑定 C……每轮都要遍历目标切片做查找。当某级数据量达数千时，线性查找会明显拖慢。
这时可考虑：
- 对关键外键字段加数据库索引（如 game_id, player_id）
- 用 map[uint]struct{} 预建 ID 查找表，手动替代 GORM 的默认挂载逻辑
- 或拆成两段查询：先 Preload("A.B")，取出 B 列表后再用 db.Preload("C").Preload("D").Find(&bs)
最易被忽略的是：GORM 不会自动优化嵌套挂载的算法复杂度，它始终用朴素遍历。数据量上来后，这比多一条 SQL 更值得调优。
