GORM连表查询需显式调用Joins或Preload，不自动关联；Joins生成SQL JOIN适用于跨表筛选/排序，Preload解决N+1适用于单纯加载关联数据，二者不可混用。
连表查询必须显式调用 Joins 或 Preload，GORM 不会自动关联
GORM 默认不执行任何 JOIN，即使模型间定义了 foreignKey 或 references。你写 db.Find(&users)，它只查 users 表；想带出订单或地址，得主动告诉 GORM “要连哪张表、怎么连”。
两种主流方式：Joins 用于 SQL JOIN（生成一条含 LEFT JOIN 的查询），适合需要跨表筛选、排序或聚合的场景；Preload 是 N+1 优化方案（先查主表，再用 IN 批量查关联表），适合单纯加载关联数据。
-
Joins返回的是扁平结构（字段可能重名，需用SELECT显式指定别名） -
Preload返回嵌套结构（如User{Orders: []Order}），但无法在关联表字段上WHERE或ORDER BY - 两者不能混用在同一查询中——
Preload会忽略Joins，反之亦然
Joins 中的 ON 条件必须手写，GORM 不推断外键关系
哪怕你在 User 模型里写了 Orders []Order ，gorm:"foreignKey:UserID"db.Joins("JOIN orders ON orders.user_id = users.id") 这句里的 ON 条件也得自己拼。GORM 不解析 struct tag 自动生成 ON 子句。
常见错误是漏掉表名前缀，比如写成 ON orders.user_id = id（id 指代不明），或者大小写不一致（PostgreSQL 对大小写敏感，Users.ID 和 users.id 可能不等价）。
- 推荐始终带上表别名：例如
db.Joins("JOIN orders o ON o.user_id = u.id").Joins("JOIN addresses a ON a.user_id = u.id").Select("u.*, o.title, a.city").Find(&results) - 如果关联字段名不标准（比如
user_id实际叫owner_id），ON条件必须按真实列名写，和 struct tag 无关 -
Joins("LEFT JOIN ...")和Joins("INNER JOIN ...")行为完全不同：前者保留左表无匹配的记录，后者只返回两边都有匹配的行
Preload 的嵌套层级和条件过滤要分步加，不能链式堆叠
Preload("Orders") 只加载所有订单；若只想加载未完成的订单，得用 Preload("Orders", func(db *gorm.DB) *gorm.DB { return db.Where("status != ?", "completed") })。这个闭包会在第二条 SQL 中生效，不影响主查询。
嵌套预加载（比如用户 → 订单 → 商品）也得逐层声明：Preload("Orders").Preload("Orders.Items")，而不是 Preload("Orders.Items") 单独写——后者会被忽略，因为 GORM 要求父级关联先被明确加载。
- 多级
Preload时，中间层级不能加条件（例如不能给Orders加Where同时又要求Orders.Items），否则第二层 SQL 会失效 -
Preload默认用IN查询，如果关联 ID 数量超数据库限制（如 MySQL 的max_allowed_packet），会报错Error 1390: Prepared statement contains too many placeholders，此时需手动分批或改用Joins - 字段零值（如
int为0）不会触发Preload，GORM 只对非零主键做批量查询
复杂连表建议用 Raw 或 Scan 配合结构体，别硬套 ORM
当连表超过 3 张、有聚合函数（COUNT、SUM）、或需要 GROUP BY + HAVING 时，强行用 Joins + Select 容易失控：字段别名难管理、空值处理麻烦、GORM 解析结果时类型映射失败（比如把 count(*) 当作 int64 但目标字段是 uint）。
更稳的做法是写原生 SQL，用 db.Raw("SELECT u.name, COUNT(o.id) as order_count FROM users u LEFT JOIN orders o ON ... GROUP BY u.id").Scan(&results)，然后定义一个纯字段匹配的结构体接收结果。
- 结构体字段名必须和 SQL 中的列别名完全一致（包括大小写），且类型要兼容（
sql.NullString接可空字符串，uint64接COUNT(*)） -
Scan不走 GORM 的 Model 映射逻辑，跳过钩子（BeforeFind等）和软删除过滤，这点务必确认是否符合业务预期 - 一旦用了
Raw，你就得自己处理 SQL 注入——参数一律用?占位符，不要字符串拼接
关联字段命名不一致、JOIN 条件遗漏、Preload 条件位置错乱、多表聚合时硬套 ORM —— 这几处最容易卡住人。实际项目里，80% 的连表问题不是语法写错，而是没想清楚“我要的是扁平结果还是嵌套结构”“要不要过滤关联数据”“有没有 NULL 值语义”。
