GORM的Preload查多对多会漏数据，因其仅执行N+1查询而不JOIN关联表，无法在主查询中使用关联字段过滤；需用Joins实现带条件的关联查询。
为什么 GORM 的 Preload 查多对多会漏数据？
因为默认只查中间表关联记录，不自动 JOIN 关联实体。比如 User 和 Role 多对多，用 Preload("Roles") 只会发起两条 SQL：先查用户，再根据 user_ids 查 role 记录——这没问题；但如果你在 WHERE 里想筛“带 admin 角色的用户”，光靠 Preload 做不到，它不参与主查询条件。
常见错误现象：db.Preload("Roles").Where("roles.name = ?", "admin").Find(&users) 会报错或查不到，因为 roles 表根本没出现在主查询的 FROM 子句里。
- 必须显式用
Joins或Scopes把关联表带进来 -
Preload是 N+1 优化手段，不是 JOIN 替代品 - 若需 WHERE/ORDER BY 关联字段，优先选
Joins+Select
用 Joins 实现带条件的多对多查询
这是最直接可控的方式，适合需要按关联表字段过滤、排序或去重的场景。GORM 会自动生成 INNER JOIN（除非你指定 LEFT）。
var users []User
db.Joins("JOIN user_roles ON users.id = user_roles.user_id").
Joins("JOIN roles ON user_roles.role_id = roles.id").
Where("roles.name = ?", "admin").
Select("users.*").
Find(&users)
- 中间表名必须和 struct tag 中
foreignKey/joinForeignKey定义一致（默认是user_id、role_id） -
Select("users.*")很关键，否则 GORM 可能返回空 struct 或字段错位 - 如果要查用户+角色名一起返回，改用
Select("users.*, roles.name as role_name")并配合适配 struct - 注意：INNER JOIN 会自动过滤掉没角色的用户；要包含无角色用户，改用
Joins("LEFT JOIN ...")
Association 方法适合什么场景？
Association 不走 JOIN，而是基于主实体 ID 批量查关联数据，适用于“已知某个用户，查他所有角色”这类明确上下文的操作。
立即学习“go语言免费学习笔记（深入）”；
var user User
db.First(&user, 1)
<p>var roles []Role
db.Model(&user).Association("Roles").Find(&roles)
- 底层执行的是类似
SELECT * FROM roles JOIN user_roles ON ... WHERE user_id = ?的语句 - 不能跨表 WHERE（比如查“这个用户的 active=1 的角色”得加
Find(&roles, "active = ?", true)） - 性能比手写 JOIN 略低（多一次查询），但代码更语义化、不易写错表关联逻辑
- 新增/删除关联用
Append/Delete，比手动维护中间表安全
中间表结构定义不匹配导致查询失败
GORM 多对多依赖中间表字段命名和外键约束。如果手动建表但字段名不标准（比如用 uid 代替 user_id），Preload 和 Association 都会查不到数据，且不报错——只会静默返回空切片。
- 检查 struct 的
gormtag：中间表 struct 应明确标注foreignKey和joinForeignKey - 例如：
type UserRole struct { UserID uint `gorm:"primaryKey;column:user_id"`; RoleID uint `gorm:"primaryKey;column:role_id"` } - 确保数据库中中间表有对应字段，且类型与主表 ID 一致（如都是
uint对应BIGINT UNSIGNED） - 用
db.Migrator().CreateTable(&UserRole{})初始化表最省心，避免手误
多对多真正麻烦的从来不是语法，而是中间表字段和 GORM 默认约定之间的那层薄纸——捅破它靠日志（开 db.Debug()）和查生成的 SQL，而不是猜。
