json.Unmarshal 默认为值类型字段新分配内存，slice/map 不复用底层数组或哈希表，导致GC压力高；应传指针、预分配slice容量、慎用匿名struct。
为什么 json.Unmarshal 默认分配多份内存
Go 的 json.Unmarshal 在解析时，只要目标变量是值类型（比如 struct{}、[]string），就会为每个字段新分配内存——哪怕你传的是已存在的变量地址。更关键的是，如果字段是 slice 或 map，它不会复用底层数组或哈希表，而是直接 make 新的。这在高频解析场景（如 API 网关、日志解析）下会明显抬高 GC 压力。
实操建议：
- 始终把目标变量声明为指针，比如
*MyStruct而非MyStruct，这样json.Unmarshal才可能复用已有内存（前提是字段本身也支持复用） - 对 slice 字段，预先用
make([]T, 0, cap)分配好容量，并确保结构体字段是[]T类型（不是*[]T），否则无法复用底层数组 - 避免嵌套匿名 struct，它们无法被
json包识别为可复用目标，强制触发新分配
json.RawMessage 是怎么跳过中间解析的
json.RawMessage 本质是 []byte 别名，不触发反序列化，只做字节拷贝。它适合“先过一遍，再按需解析”的场景，比如 Webhook 接口里只有少数字段需要立刻处理，其余字段可能存档或转发。
常见错误现象：直接把 json.RawMessage 当成字符串用，结果得到乱码或 panic —— 它只是原始 JSON 字节，没做 UTF-8 验证，也没转义。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 定义结构体字段时用
json.RawMessage，例如：Meta json.RawMessage `json:"meta"` - 后续解析必须显式调用
json.Unmarshal，且注意传入的是&rawMsg（因为RawMessage是切片，需地址才能修改底层数组） - 如果只是读取某个子字段（比如
"id"），优先用gjson或jsoniter.Get，避免整段反序列化
自定义 UnmarshalJSON 方法的边界在哪
实现 UnmarshalJSON 可以完全绕开默认分配逻辑，但代价是失去标准库的字段映射、omitempty、别名支持等。它真正有用的地方，是字段结构固定、且需要复用缓冲区的场景，比如解析大量同构日志行。
容易踩的坑：
- 忘记在方法开头调用
json.Unmarshal解析顶层对象（比如误以为自己要手动 parse `{}`），导致字段丢失 - 在方法里 new 出新 struct 并赋值给接收者，但接收者是值类型（
func (s MyStruct) UnmarshalJSON(...)），修改无效 - 未处理空值（
null）或缺失字段，导致 panic 或数据污染
示例关键点：func (s *MyLog) UnmarshalJSON(data []byte) error { ... } 必须是指针接收者；内部可用 jsoniter.ConfigCompatibleWithStandardLibrary.Unmarshal 复用已有字段内存。
哪些优化反而会让性能更差
不是所有“减少分配”都有效。有些操作看似节省内存，实则引入额外拷贝或破坏 CPU 缓存局部性。
典型反模式：
- 为每个请求 new 一个
sync.Pool对象，却没预热或没控制最大尺寸，导致 pool 内碎片化严重 - 把整个 JSON body 当作
json.RawMessage存进 map[string]interface{}，以为省事，结果 interface{} 的 type info 和 pointer 开销比原生 struct 还大 - 过度使用
unsafe.Pointer强制复用内存，但 JSON 字段长度波动大，导致越界读或静默截断
最常被忽略的一点：GC 延迟比单次分配更伤性能。与其抠每个 byte，不如让一次解析尽可能覆盖完整业务上下文——比如把用户信息、权限、配置三块 JSON 合并在一个 struct 里解析，而不是拆成三次调用。
