go中database/sql等连接池不支持自动扩缩容，仅支持按需获取/归还与空闲回收；真要实现弹性伸缩需自建监控调节逻辑，代价高且风险大。
Go 里没有“动态连接池”这个标准概念——所谓“动态”，往往是指连接数随负载自动伸缩，但 database/sql、http.Transport、pgxpool 等主流池实现都不支持运行时自动扩缩容；它们的“动态”仅体现在连接按需获取/归还、空闲连接按策略回收。真要实现弹性伸缩，得自己套壳加监控+调节逻辑，代价远高于收益。
为什么 database/sql 连接池不能自动扩容
Go 标准库的 database/sql 连接池是静态配置型：你设了 SetMaxOpenConns(50)，它就最多开 50 个，不会因为 QPS 翻倍就自动拉到 100。它只做两件事：复用、回收、排队。一旦并发请求超过 MaxOpenConns，后续请求就会阻塞在 db.Conn() 或 db.Query()，直到有连接被归还。
- 这不是 bug，是设计选择：避免突发流量把数据库打挂
-
WaitCount和WaitDuration是唯一能告诉你“排队严重”的指标，但不会触发自动扩容 - 强行封装一个“自动调大
SetMaxOpenConns”的逻辑极其危险——你改的不是本进程的连接上限，而是对数据库的连接压力上限
http.Transport 的 MaxIdleConnsPerHost 怎么配才不翻车
很多人以为设高点就能扛住突发流量，结果上线后发现 TIME_WAIT 爆满、FD 耗尽、甚至下游服务被压垮。根本原因在于：这个参数控制的是“每个 host 缓存多少空闲连接”，不是“最大并发连接数”。
- 若下游是单域名（如
api.pay.example.com），MaxIdleConnsPerHost设为 50～100 通常够用；设太高会导致大量空闲连接长期占着端口和内存 - 若下游是多子域名（如
us.api.example.com、eu.api.example.com），MaxIdleConnsPerHost再大也没用——每个 host 单独计数，总空闲连接数 = host 数 × 该值 -
IdleConnTimeout必须配合MaxIdleConnsPerHost：设 60s 就意味着连接空闲超 60s 就关，别设成 24h，否则 NAT 网关早把你踢了 - 永远不要动
http.DefaultTransport：它被很多第三方库共享，一改全崩
pgxpool 和 puddle 的 MinConns / MinIdleConns 容易被误解
pgxpool 的 MinConns 不是“最小保持活跃连接数”，而是“连接池启动时预热创建的连接数”；MinIdleConns 才是“池中始终保留的空闲连接下限”。这两个值设得不合理，会导致冷启动慢或资源浪费。
-
MinConns > 0会让应用启动时主动建一批连接，适合已知刚启动就有流量的场景；设为 0 则首次请求才建连，延迟略高但更省资源 -
MinIdleConns设太高（比如等于MaxConns）= 强制所有连接永远不释放，哪怕半小时没请求——这在云环境可能触发 LB 超时断连 - 健康检查周期
HealthCheckPeriod设太短（如 1s）会增加 DB 负载；设太长（如 10min）则失效连接可能卡住好几分钟才被剔除
真正需要“动态”能力的场景，比如突发秒杀、临时批处理，靠调参解决不了——得换思路：用消息队列削峰、加前置缓存、或拆出专用连接池隔离流量。连接池不是万能调节阀，它只是复用工具，不是弹性引擎。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
