GORM不会自动去重查询，需主动识别重复源头并用缓存、预加载、Scopes封装或批量操作等手段优化；常见重复场景包括控制器内多次相同条件查询、循环单查、重复Preload及Count误用。
直接说结论：GORM 本身不会自动去重查询，所谓“避免重复查询”不是关掉某个开关就能解决的问题，而是要你主动识别哪些查询被无意中执行了多次，并用缓存、预加载、Scopes 封装或连接复用等手段切断重复路径。
查出重复查询的源头在哪
最常见的重复发生在控制器里反复调用同一条件的 db.Where(...).Find()，比如用户列表页里先查总数、再查分页数据、又查导出用的全量——三个查询条件一模一样，只是 Limit/Offset 不同。GORM 不会帮你合并它们，数据库就真跑了三次。
- 用
db.Debug()开启日志，看相同 SQL 是否高频出现 - 检查是否在循环里写了
db.First(&u, id)—— 每次都走一次 DB 查询，而不是批量db.Where("id IN ?", ids).Find(&users) - 留意
Preload被多次调用：比如对同一个User实例连续调两次db.Preload("Profile").Preload("Orders")，GORM 会发两组 JOIN 查询
用 Scopes 封装条件逻辑，防止拼写不一致导致的“伪重复”
看起来是不同查询，其实是同一业务语义（如“只查启用状态”）被写成 Where("status = ?", "active")、Where("status = 'enabled'")、Where("is_enabled = true") 等多种变体，导致无法复用缓存或统一优化。
- 把公共条件抽成函数，例如
StatusActiveScope()和CreatedAtRangeScope() - Scopes 可组合：
db.Scopes(StatusActiveScope(), CreatedAtRangeScope(s, e)).Find(&list) - 避免在 Scope 内部做
db.Count()或db.Find()—— 它只负责修饰 *gorm.DB，不该触发执行
批量操作替代循环单查，这是最立竿见影的优化
Go 里最容易写出 N+1 查询的地方就是遍历结构体后对每个元素单独查关联，比如：
for _, order := range orders {
db.Where("order_id = ?", order.ID).First(&order.Items) // 错！N 次查询
}
正确做法是提前收集 ID，一次查完再映射：
- 提取所有
order.ID到切片orderIDs db.Where("order_id IN ?", orderIDs).Find(&items)- 用 map 构建
map[uint][]Item快速挂载到对应 order 上 - 如果必须用
Preload，确保只调一次：db.Preload("Items").Find(&orders)
别让 Count 查询污染主查询链
很多人写 db.Where(...).Limit(20).Offset(40).Count(&total)，结果 total 永远 ≤ 20 —— 因为 Count() 继承了前面的 Limit 和 Offset。这不是 bug，是 GORM 的设计逻辑。
- 必须拆开：先构建干净的查询对象
query := db.Where(...) - 再分别调用
query.Count(&total)和query.Offset().Limit().Find(&list) - 否则你以为查的是“符合条件的总条数”，实际查的是“当前页最多能有多少条”
真正难的不是写对一次查询，而是保证它在不同入口、不同上下文、不同调用链路里始终被以相同方式复用。Scopes 和批量提取 ID 是最可控的两个抓手；而依赖 Preload 自动推导或指望 GORM “聪明地合并”查询，基本等于放弃控制权。
