json.Marshal 使结构体逃逸到堆上是因为其 interface{} 参数导致编译器无法确定类型大小和生命周期，只要含指针、slice、map 或总字段超约48字节即触发逃逸。
json.Marshal 为什么会让结构体逃逸到堆上
因为 json.Marshal 接收 interface{} 类型参数，编译器无法在编译期确定实际类型大小和生命周期，只要参数含指针、slice、map 或字段总数超过约 48 字节，就大概率判定为 “escapes to heap”。哪怕你传的是栈上定义的 user := User{Name: "a"}，一旦进 json.Marshal(user)，整个结构体就可能被推上堆。
- 逃逸不是“错”，但高频调用（如网关每秒上千请求）会快速堆积小对象，加剧堆碎片和 GC 压力
- 常见触发点：结构体里有
*string、map[string]interface{}、未预分配的[]byte，或嵌套了其他逃逸字段 - 用
go build -gcflags="-m -l"看到leaking param或moved to heap提示，就是逃逸已发生
避免逃逸的三种实操路径
不是所有场景都能一刀切禁用 json.Marshal，得按数据规模、修改频率、结构稳定性选路：
- 小而固定结构体（≤48 字节，无指针/切片/map）→ 直接传值，不加
*：json.Marshal(user)比json.Marshal(&user)更少逃逸 - 中等结构体（字段多但稳定）→ 实现
MarshalJSON()方法，用bytes.Buffer+ 手动拼接，绕过反射：避免接口装箱，全程栈操作 - 大或动态结构体 → 改用
json.Encoder流式写入 + 预分配bytes.Buffer，不生成中间[]byte；若必须返回字节切片，用sync.Pool复用*bytes.Buffer，调用前buf.Reset()
别踩 sync.Pool 的坑：池化什么、怎么重置
json.Marshal 本身不能池化——它不持状态、每次返回新切片；真正该池化的，是底层缓冲区或编码器实例。
- 错误做法：
pool.Get().(*json.Encoder).Encode(v)——*json.Encoder内部的w io.Writer（比如*bytes.Buffer）没重置，残留旧数据 - 正确做法：池化
*bytes.Buffer，每次取出来后buf.Reset()，再传给json.NewEncoder(buf) - 容量控制：Buffer 初始 cap 设为典型 JSON 大小（如 2KB），避免运行时多次扩容导致新底层数组逃逸
- 禁止混用：Pool 中只放同 cap 的
*bytes.Buffer，不同尺寸 buffer 混入会污染 Pool，反而加重 mheap 压力
敏感字段控制与逃逸无关，但常被混淆
用 json:"-" 或 json:"name,omitempty" 标签只是控制字段是否出现在输出里，不影响逃逸判断。字段即使被忽略，只要它存在于结构体中且满足逃逸条件（比如是 map[string]string），仍会上堆。
立即学习“go语言免费学习笔记（深入）”；
- 想真正减少逃逸？删掉不用的字段，或把它们拆到独立结构体里，只在必要时才构造
- 别依赖
PublicUser{User: &u1}这类嵌套来“规避”——匿名指针字段本身就会触发逃逸，只是掩盖了问题 - error 字段默认序列化为
null是因接口未实现json.Marshaler，不是逃逸问题；要输出内容，得在MarshalJSON()里手动展开，而非改标签
