go-json 通过编译期生成字段绑定代码绕过反射，实测解析耗时降40%～60%、内存分配减50%+，但需导出字段+显式tag、避免interface{}和深层嵌套、复用Decoder、合理使用RawMessage和sync.Pool才能兑现性能优势。
go-json 能显著提升 JSON 解析性能，但“极致”取决于你是否绕开了反射、复用了资源、并规避了常见内存陷阱——它不是开箱即用的银弹，而是需要配合结构体定义、Decoder 复用和 RawMessage 按需解码才能兑现承诺。
为什么 go-json 的 Unmarshal 比标准库快，但你的 benchmark 可能没体现出来
go-json 在编译期生成字段绑定代码，跳过 reflect.Value 查找和接口转换，实测对 1KB 固定结构 JSON，解析耗时降低 40%～60%，分配对象减少 50%+。但如果你仍用 map[string]interface{} 或未导出字段（小写首字母），它会 fallback 到反射路径，性能优势归零。
- 必须用导出字段 + 显式
json:"field"tag，否则无法生成静态绑定 - 避免嵌套过深（>4 层）或含
interface{}字段的结构体，go-json 不支持运行时类型推导 - 别在循环里反复 new 结构体指针——即使用了 go-json，GC 压力仍来自对象分配本身
json.Decoder + go-json：流式解析才是高吞吐关键
HTTP handler 中直接调用 json.Unmarshal 会先读完整个 r.Body 到内存再解析；而 json.NewDecoder 配合 go-json，可边读边解，省掉中间 []byte 分配。注意：go-json 自带 json.NewDecoder 兼容接口，但必须显式替换 import。
- 导入要改：从
import "encoding/json"改为import json "github.com/goccy/go-json" - decoder 实例可复用：
decoder := json.NewDecoder(r.Body)后直接decoder.Decode(&v)，无需预读 - 若需多次解析同一连接（如 SSE 或批量 JSON Lines），复用
*json.Decoder实例，调用decoder.Reset(io.Reader) - 默认仍校验未知字段，需兼容旧数据时加
decoder.DisallowUnknownFields()
json.RawMessage 是零拷贝开关，但别忘了它引用原始 buffer
当结构体中存在大 payload、配置块或第三方扩展字段，且并非每次请求都需访问其内部时，声明为 json.RawMessage 可跳过整棵子树解析。go-json 对它的处理是纯字节复制，无语法检查、无内存分配。
立即学习“go语言免费学习笔记（深入）”；
- 它本质是
[]byte别名，不能直接fmt.Println，需转string(e.Payload)或再次json.Unmarshal(e.Payload, &dst) - 原始 JSON 字节来自外层解析的 buffer，若该 buffer 被 GC 或复用，
RawMessage内容可能失效 - 若后续要多次解析同一
RawMessage，务必copy出副本：payloadCopy := append([]byte(nil), e.Payload...) - 与
sync.Pool配合时，结构体里的json.RawMessage字段需在New函数中初始化为空切片，否则残留旧数据
sync.Pool 缓存结构体指针，但字段重置比你想的更严格
高频解析场景下，每秒数百次 &Event{} 分配会触发频繁 GC。用 sync.Pool 缓存指针能降低 30%+ 堆分配压力，但脏数据风险真实存在。
- Pool 的
New函数必须返回已清空状态的对象：数值字段设 0、字符串设""、slice 字段用s = s[:0]截断而非nil - 含指针字段（如
*time.Time或自定义 struct 指针）的结构体，不建议放入 Pool，除非你在 Get 后手动置nil - 别把 decoder 实例塞进 Pool——它内部有状态（如缓冲区、错误位置），并发 Put/Get 可能导致 panic
- Pool 本身无锁竞争问题，但滥用（如每次 Decode 后立刻 Put）反而增加调度开销，建议只在 QPS > 500 的服务中启用
真正卡住性能的往往不是库选错，而是结构体定义太宽、decoder 没复用、RawMessage 没隔离 dirty buffer、Pool 对象没清干净——这些细节不处理，换再快的库也白搭。
