合理缩容应设idleTimeout为30–60秒（比数据库wait_timeout小至少10秒），且仅当idleCount > MaxIdleConns/2并持续超时后，每次删1–2个、间隔≥100ms；须配合db.PingContext检测stale连接，禁用conn.Close()，缩容逻辑须在全局goroutine中异步执行。
连接池缩容触发条件怎么设才合理
自动缩容不是越激进越好，核心是避免频繁抖动。Go 的 database/sql 自带连接池（SetMaxIdleConns、SetMaxOpenConns），但它不主动缩容——空闲连接只会随 GC 慢慢回收，不会主动 close。真要动态缩容，得自己加定时器+监控逻辑。
推荐用「空闲时间 + 当前空闲数」双阈值判断：
-
idleTimeout设为 30–60 秒：比数据库端的wait_timeout小至少 10 秒，防止被服务端踢断 - 只在
idleCount > MaxIdleConns/2且持续超时后才开始逐个关闭，避免刚建好就删 - 每次最多删 1–2 个，间隔至少 100ms，给应用留出请求缓冲期
用 sync.Pool 替代连接池？别踩这个坑
有人想用 sync.Pool 管理 *sql.Conn，这是错的。sync.Pool 不保证对象复用顺序，也不感知连接状态（比如网络断开、事务未提交），直接 Get/Put 会导致 panic 或脏数据。
真正该复用的是连接对象本身，不是底层 net.Conn。正确做法是：
立即学习“go语言免费学习笔记（深入）”；
- 用
*sql.DB原生池管理连接生命周期 - 自定义一个
ConnManager结构体，封装GetConn、ReleaseConn和缩容 ticker - 在
ReleaseConn里记录最后空闲时间，供缩容逻辑读取
如何安全关闭空闲连接而不影响正在使用的连接
直接调 conn.Close() 风险很大——*sql.Conn 是从 *sql.DB 拿出来的，不是独立实例；强行 Close 会破坏内部引用计数，导致后续 Query panic。
唯一安全方式是控制 *sql.DB 的池参数并配合健康检查：
- 调
db.SetMaxIdleConns(newVal)，让池自动清理超出部分（注意：该调用是异步生效，需等下一次空闲连接归还时触发） - 缩容前对每个候选空闲连接执行
db.PingContext(ctx)，失败则立即 close（此时它已不在活跃队列中） - 永远不要调
conn.Close()，只操作*sql.DB的配置和 ping 结果
缩容逻辑放在哪里？别塞进 http handler
缩容必须脱离请求生命周期，否则高并发时大量 goroutine 同时触发缩容，反而拖慢响应。典型错误是把 ticker 放在 handler 里启动。
正确姿势是全局单例初始化时启动：
- 在
init()或main()开头启动一个常驻 goroutine，用time.Ticker - 每次 tick 扫描
db.Stats().Idle，结合自维护的空闲时间戳 map 判断 - 缩容操作本身加
sync.Mutex或原子计数保护，避免并发修改MaxIdleConns
缩容不是“越多越好”，而是“够用即止”。最易忽略的是数据库侧的连接超时设置和 Go 客户端的 timeout 不一致，会导致连接池以为连接还活着，实际已被 server 强制断开——这种 stale 连接只能靠 ping 发现，光靠计时器没用。
