*gorm.DB 是并发安全的，因其只读配置与连接池组合，每次操作生成独立 Statement；但复用 db.Session() 返回的带可变状态副本会导致数据竞争，因多个 goroutine 并发修改其 Context 或 Settings 等字段。
GORM 实例本身不是线程安全的，但 *gorm.DB 是并发安全的——前提是别复用带状态的 Session。
为什么 db.Query 不会 panic，但 db.Session(&gorm.Session{}) 之后就可能出竞态？
因为 *gorm.DB 是只读配置+连接池的组合体，所有查询/执行都走新生成的 Statement，互不干扰；而 db.Session() 返回的是带可变状态（如 Context、Logger、NowFunc）的副本，若多个 goroutine 同时修改它（比如并发调用 session.WithContext() 或 session.Statement.Settings），就会触发数据竞争。
- 常见错误：在 HTTP handler 中对同一个
session实例反复调用session.Debug().Select("id,name")，然后并发传给不同 goroutine - 正确做法：每次需要定制 Session 时，都从根
*gorm.DB新建，如db.Session(&gorm.Session{Context: ctx}) - 验证方式：用
go run -race运行服务，看是否报Write at 0x... by goroutine N / Previous write at 0x... by goroutine M
Preload 关联查询在并发下为何偶尔漏数据？
根本原因是 GORM 的 Preload 默认复用同一个 Statement 缓存 key，当两个并发请求分别对同一 model 调用 Preload("Orders") 和 Preload("Profile")，缓存 key 冲突导致后加载的关联被覆盖或跳过。
- 现象：
db.Preload("Orders").Find(&users)在压测中部分 user.Orders 为空，但日志显示 SQL 已发出 - 修复：禁用预加载缓存，显式传
Unscoped()或加唯一标识，例如db.Session(&gorm.Session{PrepareStmt: true}).Preload("Orders") - 更稳方案：改用
Joins+Scan，避免依赖 GORM 内部状态管理
struct 更新零值字段为什么会覆盖数据库原有值？
这不是线程安全问题，但高并发下放大后果——多个 goroutine 同时用同一个 struct 指针做 Save 或 Updates，若该 struct 是全局变量或复用实例，零值字段（如 int 字段为 0、string 为 ""）会被无条件写入数据库，覆盖真实值。
- 典型陷阱：
var u User; db.First(&u); u.Name = ""; db.Save(&u)—— 这里u.Age原本是 25，Save 后变成 0 - 安全写法：用 map 或 select 字段更新，如
db.Model(&u).Select("name").Updates(map[string]interface{}{"name": ""}) - 或者启用
AllowGlobalUpdate(false)防止误全表更新，配合Where("id = ?", id)显式约束范围
连接池泄漏和事务卡死，比锁竞争更常导致“伪线程不安全”现象
很多“数据错乱”报警最终查下来不是锁没加对，而是连接池耗尽后请求排队、事务超时未回滚、goroutine 卡在 rows.Next()，导致后续请求拿到脏连接或旧事务上下文。
- 必查项：
pg_stat_activity中是否存在大量idle in transaction状态 - 代码侧重点：所有
db.Raw().Rows()必须配对defer rows.Close()；所有tx, _ := db.Begin()必须用defer func() { if r := recover(); r != nil { tx.Rollback() }; tx.Commit() }()包裹 - 连接池参数要反向设限：
db.SetMaxOpenConns(70)（对应 PostgreSQLmax_connections=100），而非拍脑袋设 200
真正危险的不是“能不能并发调用”，而是“有没有隐式共享状态”。GORM 的坑多数藏在 Session 复用、struct 复用、连接/事务生命周期失控这三处——盯住这三点，比加 mutex 更有效。
