gorm默认不加载关联字段，需用preload显式加载；joins用于关联过滤/排序但不填充结构体，二者不可混用查同一表；外键为空、类型不匹配或主键未标注均导致关联为空。
关联字段没加载出来，是不是忘了 Preload？
默认情况下，GORM 不会自动加载关联结构体（比如 User 的 Profile 或 Orders），即使你定义了 gorm:"foreignKey:UserID" 这类标签。查出来的主表数据里，关联字段是零值——这不是 bug，是设计如此。
必须显式告诉 GORM 要加载哪些关联，最常用的是 Preload：
var users []User
db.Preload("Profile").Preload("Orders").Find(&users)
-
Preload对应的是has one、has many关系，底层发额外的 SQL 做 JOIN 或 IN 查询 - 字段名必须和结构体中定义的字段名完全一致（区分大小写），比如
Profile不能写成profile - 嵌套预加载用点号：如
Preload("Orders.Items")，但要注意 N+1 风险，GORM v1.25+ 对多层Preload有优化，v1.24 及更早版本可能生成低效 SQL
Joins 和 Preload 选哪个？看你要不要主表去重
Joins 是真 JOIN，适合需要基于关联字段过滤或排序的场景；Preload 是分步查询，更适合“取主表 + 附带查出所有关联”的需求。
比如要查「有订单且订单状态为 paid 的用户」：
db.Joins("JOIN orders ON orders.user_id = users.id AND orders.status = ?", "paid").
Select("users.*").
Distinct().
Find(&users)
- 用
Joins必须加Distinct()，否则一个用户有多笔订单就会重复出现多次 -
Joins不会自动填充关联结构体字段（User.Orders仍是空切片），它只影响 SELECT 和 WHERE；想同时加载数据，得配合Preload（但注意：GORM 不允许在同一个查询里混用Joins和Preload查同一张关联表，会报错） -
Preload在 WHERE 条件涉及关联表字段时无能为力（比如 “查 profile.age > 25 的用户”），这时只能换Joins+Where
一对多关联查出来却是空切片？检查外键字段是否为空或类型不匹配
常见现象：User 结构体里定义了 Orders []Order `gorm:"foreignKey:UserID"`，但 db.Preload("Orders").First(&user) 后，user.Orders 是空切片，数据库里明明有数据。
- 先确认
Order.UserID字段值是否为 NULL 或 0 —— GORM 默认忽略零值外键，不会去查关联 - 检查
UserID类型是否和User.ID一致（比如一个是uint，一个是int），类型不匹配会导致 JOIN 条件失效 - 如果用了自定义主键（比如
ID不叫ID，而是user_id），必须在User结构体上补gorm:"primaryKey"，否则 GORM 推导外键时可能出错 -
Preload的第二个参数可以加条件，例如Preload("Orders", db.Where("status = ?", "shipped"))，但注意这是对关联表的 WHERE，不是对主表
性能敏感时，别盲目 Preload 所有关联
一个 User 关联 5 张表，全 Preload 一次，GORM 会发 6 条 SQL（1 主 + 5 关联），如果并发高、数据量大，很容易打满数据库连接。
- 按需加载：接口 A 只需要
Profile，就只Preload("Profile")；接口 B 需要Orders和Address，再组合 - 避免深度嵌套：如
Preload("Orders.Items.Tags")在数据量大时极易拖慢响应，考虑前端分步拉取或改用 DTO 手动组装 - 留意 GORM 日志：
db.Debug().Preload(...).Find(...)看实际执行的 SQL，确认有没有意外的全表扫描或缺失索引
关联查询真正麻烦的从来不是语法，而是外键一致性、N+1 边界、以及什么时候该放弃 ORM 改手写 SQL —— 尤其当 Preload 和 Joins 都开始让查询变慢时，别硬扛。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
