数据库连接池配置不当、事务跨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）。
- 对可能为 NULL 的列，必须使用对应
sql.Null*类型（sql.NullString、sql.NullBool等），并检查.Valid字段 - 避免用
interface{}+ 类型断言接收 Scan 结果，易因底层 driver 返回类型差异（如[]bytevsstring）导致 panic - 批量查询建议用
rows.Scan(&v1, &v2)显式绑定，而非rows.Columns()动态解析，减少运行时不确定性
长事务 + 高并发容易触发数据库锁等待或死锁
PostgreSQL/MySQL 在 RR 或 RC 隔离级别下，并发 UPDATE/DELETE 同一行或相邻索引范围时，可能因锁升级、间隙锁或锁等待超时（如 MySQL 默认 innodb_lock_wait_timeout=50）导致操作失败，错误信息类似 ERROR: deadlock detected 或 ERROR 1205 (HY000): Deadlock found when trying to get lock。
立即学习“go语言免费学习笔记（深入）”；
- 事务粒度尽量小：只包必要 SQL，避免在事务内做 HTTP 请求、文件读写等耗时操作
- 按固定顺序访问多张表或同一表的不同行（如总是先更新 user 表再更新 order 表，且 user_id 升序），降低死锁概率
- 对冲突热点（如计数器、库存），考虑用原子 SQL（
UPDATE t SET cnt = cnt + 1 WHERE id = ?）替代 SELECT+UPDATE，减少锁持有时间
go func(){}() 就算并发”，而是每个 DB 操作单元的资源归属、错误传播、超时控制都得独立闭环。否则表面并发，实则暗藏竞态和雪崩风险。 
