json.marshal 总在堆上分配是因为其内部需构造生命周期无法静态证明的临时 []byte 和 map 等结构，即使传入 int 也走通用编码路径导致逃逸；正确优化方式是池化 bytes.buffer 并每次新建 json.encoder。
json.Marshal 为什么总在堆上分配？
因为 json.Marshal 内部必须构造临时 []byte 和 map 等结构，这些对象生命周期无法被编译器静态证明限定在函数内——哪怕你只传一个 int，它也要走通用编码路径，最终触发 escapes to heap。这不是 bug，是设计使然：它返回新切片，不持有状态，没法池化。
真正该池化的不是 json.Marshal，而是 *json.Encoder
高频序列化场景下，反复 new(json.Encoder) 或直接调用 json.Marshal 会导致每请求一次就分配数个堆对象（encoding/json.encoderState、bytes.Buffer、临时 interface{} 容器）。正确做法是池化 *json.Encoder 或更稳妥地池化 *bytes.Buffer：
- 池化
*json.Encoder时，必须重置其底层 writer：拿到后检查enc.Writer()是否为*bytes.Buffer，是则调用.Reset() - 更推荐池化
*bytes.Buffer，再每次json.NewEncoder(buf)——避免 encoder 自身状态残留 - 错误写法：
pool.Get().(*json.Encoder).Encode(v)，没 reset 就用，buffer 累积导致脏输出或 panic
逃逸分析必须加 -l 参数，否则看不准
用 go build -gcflags="-m -l" 查真实逃逸点，不加 -l 会因内联把逃逸提示错位到调用方。重点关注三类输出：
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
-
&x escapes to heap：明确取地址逃逸 -
leaking param: x：参数被外部持有（如传给 goroutine 或闭包） -
moved to heap：结构体/切片底层数组被推上堆（常见于json.Unmarshal或接口赋值）
例如 log.Info("user", user) 中 user 是值类型，会被装箱成 interface{} 并逃逸；换成 user.String() 可规避。
pprof 能抓逃逸引发的问题，但不能标出行号
pprof 不显示哪行代码逃逸，但它能暴露逃逸的后果：压测中若 runtime.mallocgc 占比高、bytes.Buffer 实例持续增长、某个 handler 的堆分配速率异常，就说明那里有逃逸源。操作步骤：
- 稳定压测（如 100 QPS 持续 2 分钟）后，用
curl "http://localhost:6060/debug/pprof/heap?debug=1"抓快照 - 对比压测前、中、后三个快照，用
go tool pprof -http=:8080查top -cum中新增分配最多的函数 - 锁定可疑函数后，再回
go build -gcflags="-m -l"验证
注意：sync.Pool 缓存的对象也会出现在 heap profile 中，别误判为泄漏——它们只是暂未回收，不是真泄漏。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
