gorm.DB 实例本身线程安全，无需额外加 sync.RWMutex；其底层 *sql.DB 已支持并发，所有公开方法可被任意 goroutine 直接调用，全局单例即可满足并发安全。
gorm.DB 实例本身不需要读写锁
很多人一看到“并发安全”就下意识加 sync.RWMutex，但 gorm.DB 是线程安全的——它底层封装的 *sql.DB 本身就是为并发设计的，所有公开方法（Create、First、Transaction 等）都可被任意 goroutine 直接调用。
你在全局只持有一个 *gorm.DB 实例（通过 sync.Once 初始化），就已经满足并发安全前提。额外套一层读写锁反而会：阻塞查询、掩盖真实瓶颈、增加死锁风险。
- 加锁后所有
db.First()必须串行执行，QPS 直接归零 -
db.Transaction()内部已用*sql.Tx管理隔离，再在外层加锁毫无意义 - 如果真要保护某个业务变量（比如缓存计数器、本地状态机），锁应该落在那个变量上，而不是
db
真正需要锁的场景是业务逻辑层，不是数据库连接层
连接池参数（SetMaxOpenConns、SetMaxIdleConns）必须在 gorm.Open() 后立即设置，且只能设一次；这些操作本身不涉及并发竞争，sync.Once 已覆盖初始化阶段的竞态。
但你的业务代码里可能有真正需要锁的地方：
- 库存扣减前检查余额 → 多个 goroutine 同时读到“足够”，然后一起扣，超卖
- 用户积分更新时先查再算再存 → 中间被其他请求改掉，结果覆盖
- 本地内存缓存（非 Redis）做计数 → 没锁就会丢更新
这时候该用 sync.Mutex 或 sync.RWMutex 保护的是具体变量，例如：
var balanceMu sync.Mutex
var userBalance map[uint64]int64
func Deduct(uid uint64, amount int64) error {
balanceMu.Lock()
defer balanceMu.Unlock()
if userBalance[uid] < amount {
return errors.New("insufficient balance")
}
userBalance[uid] -= amount
return nil
}
高并发下更该关注连接池配置和 SQL 锁，不是 Go 层加锁
当接口响应变慢、报 read: connection reset by peer 或 Too many connections，问题几乎从来不在 Go 变量竞争，而在：
-
SetMaxOpenConns设太高，MySQL 服务端扛不住 - 没设
SetConnMaxLifetime，云环境 NAT 断连后复用失败 - 事务里用了
SELECT ... FOR UPDATE但没及时提交，锁住行太久 - 批量插入没分批，单事务太长，锁表时间拉满
这类问题加 RWMutex 完全无效，反而让错误更隐蔽。你应该：
- 用
db.Stats()查InUse和WaitCount，确认是不是连接池卡住了 - 开慢日志或
EXPLAIN看 SQL 是否走了索引、有没有锁等待 - 把长事务拆短，用
FOR UPDATE NOWAIT避免无限等锁
SQLite 场景下 WAL 模式比读写锁更治本
如果你用的是 sqlite 驱动，它的写锁是库级的，sync.RWMutex 不仅没用，还会让读请求也排队——等于把并发变成串行。
正确做法是启用 WAL 模式，并调小 busy_timeout：
db, err := gorm.Open(sqlite.Open("app.db"), &gorm.Config{})
if err != nil {
panic(err)
}
_ = db.Exec("PRAGMA journal_mode=WAL;")
_ = db.Exec("PRAGMA busy_timeout=5000;") // 5秒重试，别死等
WAL 模式下读写互不阻塞，这才是 SQLite 高并发的正解。Go 层加锁只是把问题从数据库推到应用层，延迟更高、吞吐更低。
最常被忽略的一点：连接池配置和 SQL 锁行为是强耦合的，但和 Go 变量锁完全无关。别在错误的层级试图“加锁保平安”。
