必须显式配置 database/sql 连接池：SetMaxOpenConns 限制硬上限（建议设为数据库 max_connections 的 70%～80%），SetMaxIdleConns 控制空闲连接数，配合 SetConnMaxLifetime 和 SetConnMaxIdleTime 防老化连接滞留。
直接放任 goroutine 调用 db.Exec 或 db.Query，不出几秒就会触发数据库的 Too many connections 或 PostgreSQL 的 too many clients already——这不是配置没调够，是连接没管住。
database/sql 连接池必须显式限流
Go 标准库的 sql.DB 本身不设上限，默认 SetMaxOpenConns(0) 表示无限制。生产环境必须主动设值，否则每个 goroutine 都可能独占一个连接，哪怕只执行一条 SQL。
-
SetMaxOpenConns(n)：硬性上限，建议设为数据库服务端max_connections的 70%～80%，留出空间给管理连接、备份等后台任务 -
SetMaxIdleConns(n)：空闲连接保有量，通常设为MaxOpenConns / 2左右，避免频繁建连又销毁 -
SetConnMaxLifetime和SetConnMaxIdleTime（Go 1.15+）：强制刷新老化连接，防长连接卡死或被中间件（如 ProxySQL）断开后滞留
错误做法：db.SetMaxOpenConns(0) 或完全不调用这些方法；更糟的是在每次请求里 new 一个 sql.DB 实例——连接池失效，等于裸连。
别让 goroutine 数量和数据库并发数对等
你启了 1000 个 goroutine，并不意味着数据库要扛 1000 并发。连接池只是缓冲，不是放大器。真正压垮数据库的是“尖刺流量”：瞬间大量小事务争抢锁、刷 WAL、挤满 I/O 队列。
- 高频写场景下，优先用批量插入（
INSERT INTO ... VALUES (...), (...), (...)），单批控制在 100～500 行，避免触发 MySQL 的max_allowed_packet或 PG 的statement_timeout - 用
sync.Pool或带缓冲 channel 缓存待写数据，按时间（如 100ms）或数量（如 50 条）攒批落库，把毛刺削平 - 避免在循环中反复
db.Exec，哪怕每次只插 5 条——连接复用率低，照样耗尽MaxOpenConns
典型症状：pg_stat_activity 里看到大量 idle in transaction，或 MySQL SHOW PROCESSLIST 显示一堆 Sleep 状态连接，说明事务没及时结束或连接没归还。
goroutine 泄露会悄悄吃掉连接
连接没关，不等于连接池没满。常见泄露点不是忘了 rows.Close()，而是 *sql.Tx 或 *gorm.DB 实例被意外持有（比如塞进全局 map、缓存、或 defer 写在错误分支外）。
- 用
go tool pprof检查/debug/pprof/goroutine?debug=2，若发现大量database/sql.(*DB).connectionOpener或database/sql.(*Tx).awaitDone协程堆积，基本锁定泄露 - GORM 用户尤其注意：
db.WithContext(ctx).Create(...)不会自动释放连接；若 ctx 被 cancel，连接可能卡在 acquire 阶段，长期占用 slot - 所有
BeginTx必须配对Commit/Rollback，且要在 defer 外显式判断 err 后再决定提交动作，别依赖 panic recover
最隐蔽的坑：用 sync.Once 初始化 DB 实例时，误把 db.DB().SetMaxOpenConns 写在初始化函数外——配置根本没生效。
HTTP handler 里别直接起 goroutine 访问 DB
HTTP 请求生命周期短，但 DB 操作可能慢。把 DB 调用丢进 goroutine 后不等结果就返回，看似“快”，实则埋下三重雷：连接未归还、panic 无法捕获、上下文取消失效。
- 正确姿势：用 worker 模式，固定 N 个长期运行的 goroutine 从
chan *job消费任务，DB 操作统一走这个池子 - 或用
golang.org/x/sync/semaphore控制并发度，TryAcquire失败时返回 429，而不是丢进后台协程硬扛 - 绝对避免：
go handleDB(req)+defer req.Body.Close()—— body 可能还在读，DB 却已开始跑，context 超时也拦不住
连接数问题从来不是单一配置能解决的，它横跨 goroutine 调度、SQL 执行模式、事务生命周期、HTTP 处理链路四个层面。少改一处，监控曲线就多一个尖峰。
