sync.Pool 不适合存数据库连接，因其不感知连接状态，会导致复用失效连接、panic；*sql.DB 本身是完备连接池，应优化其 SetMaxOpenConns 等参数而非套用 sync.Pool。
为什么 sync.Pool 不适合直接存数据库连接
直接把 *sql.DB 或 *sql.Conn 放进 sync.Pool 会导致连接被意外关闭、复用到已失效的连接，甚至引发 panic。因为 sync.Pool 的回收逻辑不感知连接状态——它只看 GC 周期和对象是否被取走，而数据库连接必须由连接池（如 *sql.DB 内置的）统一管理生命周期、健康检查和超时控制。
-
*sql.DB本身已是线程安全的连接池，内部维护空闲连接队列、自动重连、最大空闲/最大打开数等策略，重复套一层sync.Pool只会干扰它 - 手动 Put 一个
*sql.Conn到sync.Pool后，若该连接底层 socket 已断开，下次 Get 出来直接Query就报"connection closed" -
sync.Pool中的对象可能被任意 goroutine 拿走，无法保证“同一个连接只被同一线程/上下文复用”，这反而破坏了连接绑定事务或会话变量的场景
真正该复用的是什么：业务层轻量对象
适合放进 sync.Pool 的，是那些构造开销大、无状态、可重置的业务对象，比如 JSON 解析用的 *json.Decoder、SQL 查询参数容器、自定义的请求上下文结构体等。它们不持有 fd、不依赖外部状态，Reset 后即可安全复用。
- 典型例子：
bytes.Buffer—— 复用底层[]byte底层数组，避免频繁分配；json.Encoder复用内部缓冲区 - 关键动作是实现
Reset()方法（或类似逻辑），确保每次 Get 后能回到初始可用状态，而不是靠构造函数重新初始化 - 注意：如果对象含指针字段指向外部数据（比如缓存了某个
map[string]interface{}的引用），Reset 时没清理，就会导致内存泄漏或脏数据
var bufPool = sync.Pool{
New: func() interface{} {
return new(bytes.Buffer)
},
}
// 使用时
buf := bufPool.Get().(*bytes.Buffer)
buf.Reset() // 必须调用！否则残留上次内容
buf.WriteString("hello")
// ... use buf
bufPool.Put(buf)
想优化数据库连接性能？盯紧 *sql.DB 的配置项
数据库连接复用效率取决于 *sql.DB 自身参数，不是靠外层 Pool。这些值设错，比不用 Pool 影响更大。
-
SetMaxOpenConns(n)：控制最大并发连接数，设太小会排队阻塞；设太大可能打爆数据库；建议略高于峰值 QPS × 平均查询耗时（秒） -
SetMaxIdleConns(n)：空闲连接上限，设太小会导致频繁建连/关连；设太大浪费资源；一般设为SetMaxOpenConns的 1/2 ~ 1 倍 -
SetConnMaxLifetime(d)：强制连接在数据库侧过期前主动关闭，避免用到被服务端 kill 掉的 stale 连接；推荐设为略小于数据库的wait_timeout -
SetConnMaxIdleTime(d)：空闲连接最长保留时间，防止长期空闲后首次复用时因网络中间设备断连失败；建议 5~30 分钟
什么时候真需要自己管连接？小心 sql.Conn 的生命周期
只有在需要独占连接执行多条语句（如事务、session 变量设置、prepare 复用）时，才该显式 db.Conn(ctx) 获取 *sql.Conn。但此时绝不能把它扔进 sync.Pool，而必须严格遵循“Get → Use → Close”流程。
立即学习“go语言免费学习笔记（深入）”；
-
*sql.Conn不是线程安全的，不能跨 goroutine 复用；Close 后不能再用，也不能 Put 到任何池里 - 常见错误：defer conn.Close() 后又在别的地方继续用该 conn，触发
"sql: connection is already closed" - 更隐蔽的坑：conn.Close() 实际是归还给
*sql.DB的底层池，不是真正关 socket；所以它仍可能被其他 goroutine 下次 Get 到——但这正是设计意图，不需要你操心
复杂点在于：一旦你开始手动管理 *sql.Conn，就等于绕过了 *sql.DB 的自动健康检测。如果连接中途断开，你得自己捕获 driver.ErrBadConn 并重试，或者换连接。
