Go 的 database/sql 连接池无需手写，关键在合理配置：SetMaxOpenConns、SetMaxIdleConns、SetConnMaxLifetime 必须设，初始化后需 db.Ping()；pgxpool 的 MinConns 和 HealthCheckPeriod 易配错；gRPC 客户端本身已内置连接池，不应重复实现。
database/sql 连接池不是“要实现”，而是“要配准”
Go 里根本不需要手写 database/sql 连接池——它已经内置在 sql.DB 里。所谓“高性能”，90% 取决于参数是否合理，而不是代码是否精巧。
-
SetMaxOpenConns必须设：默认 0 表示无上限，等于把数据库的max_connections全部暴露给应用；建议按「峰值 QPS × 平均查询耗时（秒）× 1.5」估算，再取数据库硬上限的 70%（如 MySQL 默认 151 → 最高设 100） -
SetMaxIdleConns必须 ≤SetMaxOpenConns：Go 1.12+ 遇到违反直接 panic，错误信息是"max idle conns exceeds max open conns"；生产常用值为后者的 1/2～2/3 -
SetConnMaxLifetime不是保活，是主动换新：设为略小于 DB 侧超时（如 MySQLwait_timeout=300s→ 设240 * time.Second），否则复用被 RDS Proxy 静默断掉的连接，会触发invalid connection错误 - 初始化后必须调
db.Ping()：否则第一次Query才报错，故障定位延迟严重
pgxpool 的 MinConns 和 HealthCheckPeriod 容易配错
用 pgxpool 时，MinConns 不是“预热数量”，而是“强制维持的最小空闲连接数”。配太高会提前占满连接、压垮数据库；配太低则突发流量下建连延迟陡增。
-
MinConns建议设为MaxConns × 0.2（如MaxConns=20→MinConns=4），避免冷启动抖动，又不浪费资源 -
HealthCheckPeriod设太短（如 5min）会导致失效连接滞留过久；推荐 30s～2min 区间 - 健康检查失败不自动剔除连接：pgxpool 默认只记录日志，需配合
AfterConnect或外部监控做主动熔断
自研 TCP/HTTP 连接池绕不开三个底层约束
标准库没提供通用连接池，但自己写极易漏掉关键机制。最常踩的坑不在并发控制，而在连接生命周期管理。
- 空闲连接必须带健康检查：仅靠
Put归还不够，下次Get可能拿到已断连；建议在Get前加轻量探测（如SetReadDeadline(10ms)+ 尝试读 1 字节），失败则丢弃并新建 -
SetConnMaxIdleTime（Go 1.15+）比自己维护时间戳更可靠：它由 runtime 自动清理空闲超时连接，且与SetConnMaxLifetime协同（前者管空闲期，后者管总寿命） - 归还逻辑必须幂等：网络错误可能导致
Put被重复调用，或Get成功但业务 panic 未走到Put；应在Put入口判断连接状态（如conn.RemoteAddr() != nil），避免 double-close
gRPC 客户端根本不需要连接池
你写的“gRPC 连接池”大概率是错的。因为 *grpc.ClientConn 本身已是连接复用抽象，内部已实现连接管理、重试、负载均衡（如 round_robin）和健康探测。
立即学习“go语言免费学习笔记（深入）”；
- 反复
grpc.DialContext创建新ClientConn：不仅无法复用连接，还会导致 fd 泄漏、DNS 缓存失效、TLS 握手开销翻倍 - 用
sync.Pool包裹*grpc.ClientConn：conn 关闭后不可复用，Pool 可能返回已关闭实例，造成panic: send on closed channel或静默失败 - 正确做法：进程启动时单次
grpc.DialContext，全局复用；进程退出前调conn.Close()；通过WithBlock()和WithTimeout控制初始建连行为
复杂点往往藏在边界条件里：比如 SetConnMaxIdleTime 和 SetConnMaxLifetime 同时设置时的优先级、pgxpool 在事务中提前释放连接的副作用、或者 db.Stats().WaitCount 持续上升却没触发告警——这些都不是配置文档里会明说的，得靠线上指标反推。
