sync.Pool适合生命周期短、创建开销高、状态可重置的临时对象，如gin.Context、fmt.pp等；不适合数据库/TCP连接、有外部依赖或状态不可控的对象。
sync.Pool 适合哪些场景
sync.Pool 只适合生命周期短、创建开销高、且状态可重置的临时对象 —— 它不是通用缓存，更不是连接池。比如：gin.Context、fmt.pp、encoding/json.scanner 这类对象，每个请求/每次调用都新建一个，用完即弃，正是它的理想用武之地。
- 高频短命对象：HTTP 请求处理中的上下文、日志结构体、序列化缓冲区等
- 大中型结构体（≥ 几百字节）：小对象（如
int、string）放 Pool 反而增加调度开销，得不偿失 - 初始化成本高：含预分配切片、嵌套 map、复杂字段初始化的对象
- 无外部依赖或闭包捕获：不能持有
http.Request、数据库事务、goroutine 局部变量等“活引用”
为什么不能用来存数据库连接或 TCP 连接
因为 sync.Pool 的对象随时可能被 GC 清理（包括 victim cache 回收阶段），且不保证复用顺序或存活时间。你 Put 一个连接，下次 Get 到的可能是 nil、已关闭的连接，甚至完全不同的对象。
- 连接类对象需显式健康检查、超时控制、归还校验 ——
sync.Pool不提供任何这些能力 - 标准库明确警告：“Pool 不适合保存有状态的对象，如数据库连接、TCP 连接”
- 真要复用连接，请用
database/sql.DB或net/http.Transport这类自带连接池的成熟组件
Put 和 Get 必须配对 + 状态重置
对象从 sync.Pool.Get() 拿出来时，内容不可信；放进 sync.Pool.Put() 前，必须清空所有可变状态 —— 否则下个 goroutine 拿到的就是脏数据。
func (s *RequestData) Reset() {
s.UserID = 0
s.Payload = s.Payload[:0] // 避免底层数组残留
s.Headers = nil // 或 s.Headers = make(map[string][]string, 0)
}
// 使用流程：
data := reqPool.Get().(*RequestData)
data.Reset() // ← 关键！不能省
data.UserID = 123
// ... 处理逻辑
reqPool.Put(data)
- 不要依赖字段默认零值：结构体字段可能因内存复用保留旧值
- 切片用
s.Slice = s.Slice[:0]而非s.Slice = nil（避免后续 append 触发新分配） - map、channel、指针字段建议显式重置，除非 New 已确保初始为空
容易被忽略的性能陷阱
sync.Pool 不是银弹。滥用反而拖慢程序，尤其在低并发或对象极轻量时。
立即学习“go语言免费学习笔记（深入）”；
- Pool 本身有锁竞争（local shared 队列用 mutex）、victim cache 跨 P 搬运开销
- 对象太大（如几 MB）会卡住 GC 扫描，反而加剧 STW 时间
- 若
New函数里做耗时操作（如打开文件、发起 HTTP 请求），等于把瓶颈移到了 Get 路径上 - 实测建议：先用
go test -bench=.对比加 Pool 前后，确认分配次数（B.AllocsPerOp）下降、耗时减少
最危险的错觉，是以为 Put 过的对象一定会被复用 —— 它可能下一秒就被 GC 当作垃圾扫掉，也可能一直躺在 victim 里无人问津。写代码时，永远按「每次 Get 都是全新对象」来设计。
