别让GORM每次都查一遍，应使用Preload一次性加载关联、Scopes封装条件逻辑、全局*gorm.DB复用连接池；重复查询本质是结构混乱与流程失控，而非单纯性能问题。
直接结论：别让 GORM 每次都查一遍，用 Preload 一次性加载关联，用 Scopes 封装条件逻辑，用全局 *gorm.DB 实例复用连接池——重复查询本质是结构混乱+流程失控，不是性能调优问题。
Preload 解决 N+1 关联查询
当你写 db.Find(&users) 然后遍历每个 user 再调 db.Where("user_id = ?", user.ID).Find(&orders)，就掉进 N+1 坑里了。GORM 不会自动合并，它真的一条一条发 SQL。
- ✅ 正确做法：用
Preload显式声明要一起查的关联字段，比如db.Preload("Orders").Find(&users)，GORM 会生成两条 SQL：一条查users，一条用IN查所有相关orders - ⚠️ 注意点：
Preload("Orders.Status")这种嵌套写法只在关联模型也定义了对应字段时才生效；若Order没定义Status字段，会静默失败，不报错也不加载 - ? 条件过滤要写在第二个参数里：
db.Preload("Orders", "status = ?", "paid")，而不是链式调用Where，否则条件作用于主查询而非关联查询
Scopes 封装重复的 Where 条件
电商后台里“按时间范围筛选”“按状态过滤”这种逻辑，在 5 个接口里复制粘贴，改一处漏四处。这不是代码量问题，是维护成本爆炸的前兆。
- ✅ 把条件抽成函数：
func DateRangeScope(start, end string) func(*gorm.DB) *gorm.DB，返回一个接收*gorm.DB并返回新*gorm.DB的闭包 - ✅ 组合使用：
db.Scopes(StatusScope(status), DateRangeScope(start, end)).Find(&orders)，可读性高，修改一处，全部生效 - ⚠️ 避坑：不要在 Scope 函数里调
db.Find()或db.Create()，Scope 只负责修饰查询链，执行交给调用方
全局 DB 实例避免连接与配置重复初始化
每次操作都写 gorm.Open(...)，等于每次新建连接池——不仅慢，还会快速耗尽数据库连接数，尤其在并发场景下。
立即学习“go语言免费学习笔记（深入）”；
- ✅ 在
database包里定义var db *gorm.DB，在init()中完成gorm.Open、LogMode(false)、SetMaxOpenConns等一次性配置 - ✅ 所有业务代码直接用这个
db，它本身就是线程安全的，底层复用database/sql连接池 - ⚠️ 切记：
db.Session(&gorm.Session{...})是临时会话，不影响全局db配置；但如果你在某个函数里又调了一次gorm.Open，那就是实打实的资源泄漏
查重逻辑不能依赖 GORM 自动推断
GORM 对 PlaceID 这类业务唯一字段完全无感。你写 db.Create(&message)，哪怕 Location 表里已有相同 PlaceID，它照样 INSERT，直到 PostgreSQL 报 ERROR: duplicate key value violates unique constraint "locations_place_id_key"。
- ✅ 必须显式查重：
db.Where("place_id = ?", placeID).First(&existingLoc)，再决定是复用 ID 还是新建 - ✅ 关联创建必须拆开：先
Create主记录，再手动处理Locations切片，对每个loc查重 + 关联（或用Save更新中间表） - ⚠️ 特别注意
BeforeCreate钩子：如果Location定义了该钩子且生成新 UUID，那即使你查到了已有记录，也会因钩子触发导致 ID 被覆盖，最终仍插入重复数据
最常被忽略的其实是第三点：很多人以为“只要用了 Preload 就不重复查询了”，却没意识到连接初始化、日志开关、连接池参数这些配置如果散落在各处，每一次查询背后都在重复做无意义的系统调用。真正的“避免重复”，是从初始化那一刻就开始控制。
