数据库连接池配置不当、事务跨goroutine使用、Scan类型不匹配、长事务及锁竞争是Go并发DB操作四大隐患，需分别优化连接参数、限定事务作用域、规范空值处理、缩小事务粒度并避免死锁。
数据库连接池配置不合理会导致大量 goroutine 阻塞
Go 的 database/sql 自带连接池，但默认配置（MaxOpenConns=0、MaxIdleConns=2）在高并发下极易成为瓶颈。当并发请求超过空闲连接数且新连接未及时建立时，db.Query 或 db.Exec 会阻塞等待，goroutine 积压，最终拖垮服务。
-
MaxOpenConns建议设为略高于峰值 QPS（如 QPS 100 → 设为 120），避免连接耗尽；设为 0 表示无限制，但可能压垮数据库 -
MaxIdleConns应 ≤MaxOpenConns，通常设为MaxOpenConns的 1/2～2/3，减少连接反复创建销毁开销 - 务必调用
db.SetConnMaxLifetime（如 30m）和db.SetConnMaxIdleTime（如 5m），防止 stale connection 和连接泄漏
事务内不能跨 goroutine 使用同一个 *sql.Tx
*sql.Tx 不是并发安全的。在事务中起 goroutine 并复用该 tx 执行查询或更新，大概率触发 sql: Transaction has already been committed or rolled back 或静默失败——因为主线程可能已提前 Commit()/Rollback()，而子 goroutine 还在用已失效的句柄。
- 事务必须严格限定在单个 goroutine 内完成：从
db.Begin()到tx.Commit()或tx.Rollback()之间不 spawn 新 goroutine 操作该tx - 若需并行执行多个独立 DB 操作，应为每个 goroutine 分配独立的
*sql.DB句柄（走连接池）或各自Begin()新事务 - 切勿把
tx当参数传给异步函数，也不要在闭包里捕获并延迟使用它
Scan 时未处理 sql.Null* 或类型不匹配会 panic
并发场景下，panic 更危险：一个 goroutine panic 若未 recover，可能终止整个程序（尤其没启用 recover 的 HTTP handler）。常见于 SELECT nullable_column FROM t 后直接 Scan 到非空类型（如 int 而非 sql.NullInt64）。
