能全局复用，但必须满足两个硬条件：已成功gorm.Open返回且未手动修改db.Statement等内部字段；常见错误是包级声明var db *gorm.DB却在ListenAndServe后初始化，导致nil指针panic。
gorm.DB 实例本身是并发安全的，但初始化时机、连接池配置和 Preload 写法这三点没做对，多协程一跑就 panic 或查错库。
gorm.DB 实例能不能全局复用？
能，但必须满足两个硬条件：已成功 gorm.Open 返回，且没手动改过 db.Statement 或内部字段。常见错误是把 var db *gorm.DB 声明在包级，却在 http.ListenAndServe() 之后才调用 initDB() —— 此时所有 goroutine 拿到的都是 nil 指针，直接 panic “invalid memory address”。
- 初始化必须在
main()启动阶段完成，失败要显式退出，不能靠 defer 或中间件兜底 - 结构体字段必须声明为
*gorm.DB，不是gorm.DB（值类型会导致拷贝后连接池失效） - 用 DI（如 wire）时，给每个 DB 实例绑定唯一类型别名，比如
type UserDB *gorm.DB，避免容器注入错实例
Preload 关联查询在并发下怎么写才不 N+1？
并发中单独对每个对象调用 Association().Find() 是最典型的退化写法，它会让 N 个 goroutine 各自发 N 条 SQL，变成 N² 次查询。GORM 的 Preload 和 Joins 才是并发安全的批量加载方案。
- 正确：先
db.Preload("Orders").Find(&users)→ 2 条 SQL（主表 + 关联表），所有 goroutine 共享同一预加载结果 - 更高效：用
db.Joins("JOIN orders ON ...").Select("users.*, orders.amount").Find(&results)→ 1 条 SQL，避免多次 round-trip - 禁止：在 for 循环或 goroutine 里拼
IN子句模拟预加载 —— 容易超长、SQL 注入、类型不匹配
连接池参数不设会出什么问题？
默认 MaxOpenConns=0（无上限）、MaxIdleConns=2，压测时立刻出现 dial tcp: connect: cannot assign requested address 或大量超时。这不是 GORM 本身的问题，而是底层 sql.DB 连接池失控。
- 必须在
gorm.Open后立即调用：db.DB().SetMaxOpenConns(50)、db.DB().SetMaxIdleConns(10) - 配对设置生命周期：
db.DB().SetConnMaxLifetime(30 * time.Minute)和db.DB().SetConnMaxIdleTime(10 * time.Minute)，否则 MySQL 的wait_timeout会断连且 GORM 不重连 - 别信“连接池自动管理”——GORM 不会帮你调这些，漏设等于裸奔
真正容易被忽略的是：事务、Context、Session 这三者混用时的生命周期错位。比如在中间件里反复调用 db.WithContext(c.Request.Context()) 生成新实例没问题，但若把这个实例缓存进 map 跨请求复用，context 就会提前 cancel，后续查询静默失败。这种 bug 很难复现，只在高并发长连接场景下暴露。
