因为sync.Pool的Put()不重置状态，Get()可能返回带残留数据的bytes.Buffer，导致String()返回脏数据；必须每次Get后立即调Reset()清空，否则引发数据污染。
为什么 Gin 中的 bytes.Buffer 用完不 Reset 就会出错
因为 sync.Pool 的 Put() 不清空状态，Get() 拿到的 bytes.Buffer 很可能还带着上次写入的字符串。比如中间件里写了 buf.WriteString("user_id=123") 后直接 Put(buf)，下个请求 Get() 到的 buffer 一调 String() 就返回 "user_id=123..." 开头的脏数据——这不是 bug，是设计如此。
-
bytes.Buffer必须在每次Get()后立刻调用buf.Reset() - 不能只置
buf = nil或新建局部变量，那只是丢弃引用，池里对象还在 - 如果用了
buf.Grow(n)预分配，Reset 仍能复用底层数组，不会退化为新分配
Gin 中间件里怎么安全复用结构体对象
比如你定义了 type RequestContext struct { UserID int; Data map[string]string }，想在中间件中复用它，必须确保每个字段都可重置。否则 UserID 留着上个请求的值，Data map 里键值残留，就是典型的数据污染。
-
UserID字段直接赋零：req.UserID = 0 -
Data是 map，不能只写req.Data = nil，得遍历清空：for k := range req.Data { delete(req.Data, k) }，或更高效地req.Data = make(map[string]string) - 如果结构体含
*sync.Mutex，Put 前必须已解锁，否则下次 Get 拿到锁住的实例，Lock()直接 panic -
New函数里别复用全局实例，必须每次return &RequestContext{Data: make(map[string]string)}
为什么高并发下 sync.Pool 反而变慢
不是 Pool 写错了，而是 Goroutine 跨 P（逻辑处理器）调度太频繁。Gin 默认每请求起一个 goroutine，如果中间件里有 channel 阻塞、time.Sleep 或 runtime.Gosched()，这个 goroutine 很可能被调度到另一个 P 上，导致本地池 miss，被迫去其他 P 的 shared 队列抢锁取对象。
- 刚
Put()的对象，Get()不一定拿得到——这是常态，不是 bug - 没预热的 Pool 在压测初期几乎全是
New()调用，起不到缓存作用 - 对象大小超过 2KB 或每秒 Get/Put 超百万次时，Pool 自身开销可达 CPU 5%～10%
- 验证是否生效，别看 GC pause，要看
go tool pprof -alloc_space里bytes.makeSlice或结构体new是否明显下降
Get() 返回 nil 怎么处理才不崩
sync.Pool.Get() 完全可能返回 nil，尤其在刚启动、GC 清空后、或池为空时。Gin handler 里如果直接断言类型，比如 buf := bufPool.Get().(*bytes.Buffer)，遇到 nil 就 panic。
立即学习“go语言免费学习笔记（深入）”；
- 必须检查：
v := bufPool.Get(); if v == nil { buf = new(bytes.Buffer) } else { buf = v.(*bytes.Buffer) } - 或者更简洁：
buf := bufPool.Get(); if buf == nil { buf = new(bytes.Buffer) }; b := buf.(*bytes.Buffer); b.Reset() - 千万别在
New里写return bufPool.Get()，会触发循环引用和 “sync: inconsistent pool behavior” panic - Pool 中的对象随时可能被 GC 清掉，所以它只适合“用完即弃”的临时对象，不能当长期缓存用
Reset 和 New，而是判断这个对象值不值得放进 Pool：它得高频创建（QPS ≥ 1k）、短命（生命周期 ≤ 单次 HTTP 请求）、结构稳定（字段可全量归零）、且逃逸到堆（go build -gcflags="-m" 确认）。其余情况，直接 new 更干净。 
