iris 框架不内置 sync.pool，需手动配置；应池化 bytes.buffer、预分配 []byte、带 reset() 的 dto 指针、json.encoder/decoder；避免大对象、含长生命周期引用的对象；get 后必须 defer put 并 reset；注意逃逸分析与 new 函数轻量初始化。
sync.Pool 不是 Iris 特有的，得自己配
Iris 框架本身没有内置的 sync.Pool 管理机制，也不会自动帮你池化 *http.Request、*iris.Context 或 JSON 编码器这类对象。所有对象复用都得你手动声明包级 sync.Pool 变量，并在 handler 中显式 Get/Put。Iris 的 Context 是每次请求新建的（逃逸到堆），不复用；它只是个轻量 wrapper，真正要池化的，是你 handler 里高频创建的临时对象。
哪些对象值得放进 Pool：看生命周期和可重置性
不是所有变量都适合池化。在 Iris handler 中，真正能靠 sync.Pool 显著降 GC 的，只有这几类：
-
*bytes.Buffer：构造响应体、拼接日志、写入中间结果最常见，Reset()成本极低 -
[]byte切片（预分配容量）：比如反序列化时读取 HTTP body，make([]byte, 0, 4096)比每次都make([]byte, len)更稳 - 自定义 DTO 结构体指针（如
*UserResponse）：必须带Reset()方法清空字段，且不含不可控指针（如未归零的map或slice） - JSON 编码器/解码器（
*json.Encoder/*json.Decoder）：需绑定到bytes.Buffer或io.Writer，注意不要绑定到网络连接
别往 Pool 里塞大对象（>32KB）、含长生命周期引用的对象（比如绑了 context.WithValue 的结构体），也别塞 string 或 int —— 复用收益远低于同步开销。
handler 中正确使用 Get/Put 的模式
错误写法是只 Get 不 Put，或在 goroutine 里异步 Put（导致对象被提前归还、被其他请求误用）。标准做法是用 defer 配合作用域控制：
func userHandler(ctx iris.Context) {
buf := bufferPool.Get().(*bytes.Buffer)
defer bufferPool.Put(buf)
buf.Reset()
// 构造响应
resp := UserResponse{ID: 123, Name: "Alice"}
json.NewEncoder(buf).Encode(resp)
ctx.ResponseWriter().Write(buf.Bytes())
}
关键点：
-
Get()返回值必须类型断言，且断言失败时会 panic —— 所以New函数必须返回非 nil 对象 -
Reset()必须在Put()前调用，否则脏数据（如旧 map key、残留 slice 元素）会污染下一个使用者 - 不能把
buf传给另一个 goroutine 后再Put，那等于“借出去没还”，池子会慢慢变空 - GC 会清空 Pool，所以永远别假设
Get()一定返回之前Put过的对象
容易被忽略的陷阱：逃逸分析 + Pool 初始化时机
很多人写了 sync.Pool 却没效果，根本原因是对象根本没逃逸到堆 —— 编译器把它优化到栈上了，压根不走 Pool。用 go build -gcflags="-m" main.go 看关键变量是否 escape。如果 buf 在 handler 内部没逃逸，sync.Pool 就是画蛇添足。
另一个坑是 New 函数里做重活：比如在 New 里初始化数据库连接、打开文件、或调用阻塞 API —— 这会让首次 Get() 变慢，甚至卡住整个 P 的本地池。应该只做轻量初始化，例如 return &UserResponse{Header: make(map[string]string, 4)}。
最后，Pool 对象不会跨 GC 周期存活，也没有“预热”保障。如果压测初期 QPS 突增，Pool 里没对象，就会触发大量 new，反而比不用 Pool 更抖。真要预热，得在 init() 里手动 Put 几十个干净对象进去 —— 但这仅适用于稳定流量场景，动态扩容服务慎用。
