需要跨表筛选或排序时用joins；只为了带出关联数据、不参与where或order by时用preload。joins生成单条left join sql但需手动select字段，preload发n+1查询并自动填充嵌套结构，混用会导致空结果或性能问题。
联合查询时 GORM 的 Joins 和 Preload 怎么选？
直接说结论：需要跨表筛选或排序时用 Joins；只为了带出关联数据、不参与 WHERE 或 ORDER BY 时用 Preload。两者生成的 SQL 完全不同，混用会导致意外空结果或 N+1。
常见错误是看到文档里都支持“一对多”，就默认 Preload 能替代 Joins —— 实际上 Preload 是两条独立 SQL（主表查完再查子表），根本不会生成 JOIN；而 Joins 是单条 LEFT JOIN，但必须手动指定 Select 字段，否则 GORM 默认只映射主表结构。
-
Joins("JOIN users ON posts.user_id = users.id")后必须跟Select("posts.*, users.name as user_name")，否则users.name不会进入结果结构体 -
Preload("User")适合展示场景，但无法实现 “查出所有 post 且 user.status = 'active'” 这类带关联表条件的过滤 - 如果用了
Joins又没加Unscoped()，软删除字段（deleted_at）会自动生效，可能把本该 JOIN 出来的关联记录过滤掉
结果映射到嵌套结构体时字段名冲突怎么处理？
GORM 默认按结构体字段名匹配列名，但 JOIN 后多个表有同名字段（比如 id、created_at）就会覆盖。不能靠 Alias 解决，得靠 SQL 别名 + 结构体标签双配合。
例如两个表都有 id，你写 SELECT posts.id AS post_id, users.id AS user_id，对应结构体就得这么定义：
type PostWithUser struct {
PostID uint `gorm:"column:post_id"`
UserID uint `gorm:"column:user_id"`
UserName string `gorm:"column:user_name"`
Title string `gorm:"column:title"`
}
- 别名必须和
column:标签完全一致，大小写敏感 - 不能只改 SQL 别名却不改结构体 tag，GORM 不会自动推导
- 如果嵌套结构体（比如
User User字段），GORM 无法自动解包 JOIN 结果，必须平铺字段，否则字段为空
使用 Scan 接收联合查询结果要注意什么？
Scan 是最灵活也最容易出错的方式：它绕过 GORM 的模型映射逻辑，直接按顺序把 SQL 列填进目标结构体字段。一旦列顺序或数量对不上，字段就为零值，且无任何报错提示。
典型陷阱是修改了 SELECT 字段顺序但忘了同步调整结构体字段顺序，或者在中间加了计算字段（如 COUNT(*)）导致偏移。
- 务必用
SELECT显式列出所有字段，避免用*—— 表结构变更后极易崩 - 结构体字段顺序必须和
SELECT中列的顺序严格一致 - 如果某列可能为 NULL（比如 LEFT JOIN 的右表字段），对应字段类型要用指针（
*string）或 sql.NullString，否则 Scan 会 panic -
Scan(&v)的v必须是指针，且类型需提前声明，不能是interface{}
Gin 中返回联合查询结果时 JSON 序列化丢失字段怎么办？
不是 GORM 的问题，是 Go 的 JSON 序列化规则：首字母小写的字段（哪怕有 json: tag）默认被忽略。联合查询结果常因字段命名不规范（比如 user_name）而被迫用小写开头变量，结果 API 返回空字段。
- 结构体字段名必须大写开头，tag 里写小写别名：
UserName string `json:"user_name"` - 别用
map[string]interface{}临时拼接，类型丢失、无编译检查、嵌套深了易出错 - 如果字段名来自数据库别名（如
posts.created_at），别名建议转成驼峰（post_created_at → PostCreatedAt），比硬塞下划线更可控 - Gin 的
c.JSON(200, data)不会报错，但字段消失时很难定位，建议在开发期加一层断点或打印json.Marshal(data)看原始输出
联合查询真正麻烦的从来不是语法，而是字段生命周期管理：SQL 别名 → 结构体 tag → JSON tag → 前端字段名，任一环脱节就静默失败。
