直接复用 sync.Pool 中的结构体实例 + 预分配字段能显著降低 GC 压力和内存分配开销，因 json.Unmarshal 默认为每次调用分配新实例，含 []byte 或 map 的结构体会触发底层数组多次扩容，高频场景下易导致 STW 上升与 P99 延迟抖动。
直接复用 sync.Pool 中的结构体实例 + 预分配字段，能显著降低 GC 压力和内存分配开销，尤其在每秒数百次以上 JSON 响应的 API 场景中效果明确。
为什么结构体不能每次 new 而要池化
Go 的 json.Unmarshal 和 json.Marshal 默认会为每个调用分配新 struct 实例。若结构体含 []byte、map 或嵌套 slice，还会触发底层数组多次扩容 —— 这些都是 GC 的主要压力源。高频接口（如用户查询、订单状态轮询）下，对象创建速率可能远超 GC 回收节奏，导致 STW 时间上升、P99 延迟抖动。
- struct 字段未显式初始化时，
json.Unmarshal会覆盖但不清空旧 slice 底层数组，造成内存残留或越界读 - pool 中对象若被长期持有（比如写入 channel 后未及时消费），会阻塞复用，反而加剧内存泄漏
- 别把整个
*http.Request或*sql.Tx放进 pool —— 它们生命周期由框架/驱动管理，手动池化易出错
如何正确声明和使用 sync.Pool
关键不是“放进去”，而是“拿出来后怎么重置”。池中对象必须可安全复用，即字段值与上次使用无关。最稳妥的方式是：预分配常见大小的 slice，并在每次取出后显式清空或重置。
- 用
make([]byte, 0, 512)预分配容量，避免小 payload 下反复扩容 - 对 map 字段，复用前执行
clear(m)（Go 1.21+）或m = make(map[string]string) - 数字/字符串字段必须赋零值（如
e.ID = 0、e.Name = ""），不能依赖结构体字面量默认值 - pool 的
New函数只在无可用对象时调用，不要在里面做耗时操作（如打开文件、建 DB 连接）
Encoder 复用比 struct 复用更值得优先做
json.Encoder 内部持有缓冲区和状态机，每次新建都分配新 bufio.Writer。相比结构体，它复用收益更高、风险更低 —— 只要不跨请求复用同一个 encoder 实例即可。
立即学习“go语言免费学习笔记（深入）”；
- 在 handler 内部按需创建
json.NewEncoder(w)是安全的，但不要把它存成包级变量 - 若响应体固定且小（如
{"status":"ok"}），可预序列化为[]byte直接w.Write()，跳过 encoder 开销 - 别尝试复用
json.Decoder，它的io.Reader绑定不可变，且内部状态复杂，复用极易出错
容易被忽略的边界：json.RawMessage 引用生命周期
当结构体含 json.RawMessage 字段时，它只是原始字节切片的包装，不复制数据。这意味着：如果从 request body 读取的 []byte 被池化复用，而 RawMessage 仍引用其旧底层数组，后续解析就会读到脏数据。
- 务必确保
RawMessage字段在复用前被置空：e.Payload = nil或e.Payload = e.Payload[:0] - 禁止把
RawMessage持久化到 goroutine 外（如发到 channel、存 DB 前未拷贝），否则原 buffer 被 pool 回收后数据失效 - 若需透传 JSON 片段，优先用
io.Copy直接写入 response body，而非先解再 Marshal
