真实吞吐量需复用缓冲与结构体、避免逃逸、监控分配：b.Run内重读JSON、new结构体、b.ReportAllocs()，大JSON瓶颈在内存带宽与GC，非CPU。
Go json.Unmarshal 基准测试怎么写才反映真实吞吐量
直接用 testing.B 跑 json.Unmarshal 很容易测出虚高数字——因为小样本、无内存复用、忽略 GC 干扰。真实吞吐量取决于：是否复用 []byte 缓冲、是否复用目标结构体、是否触发频繁堆分配。
- 每次
b.Run内必须重新读取原始 JSON 数据（不能在B.ResetTimer()外提前解码一次） - 目标结构体建议在
b.Run内 new，避免指针逃逸污染后续迭代 - 用
b.ReportAllocs()观察每次解码的平均堆分配字节数，>0 说明有不可避的分配，会影响高并发吞吐 - 示例中别用
map[string]interface{}——它比结构体慢 3–5 倍且分配更多，除非你真需要动态 schema
大 JSON（>1MB）下 json.Unmarshal 的瓶颈在哪
不是 CPU，是内存带宽和 GC 压力。当单次 JSON 超过几 MB，json.Unmarshal 会大量调用 runtime.mallocgc 创建嵌套 map/slice/strings，这些对象在下次 GC 时集中清扫，导致 STW 时间拉长，吞吐抖动明显。
- 用
go tool pprof -http=:8080 cpu.prof看火焰图，如果runtime.mallocgc或runtime.gcStart占比高，说明是 GC 主导瓶颈 -
encoding/json不支持零拷贝解析，所有字符串都会复制一份，无法规避内存占用 - 若 JSON 结构固定，改用
easyjson或go-json可减少 40%+ 分配，但需生成额外代码
对比 go-json 和标准库时要注意的兼容性陷阱
go-json（github.com/goccy/go-json）快，但默认行为和标准库不一致：比如对空字符串字段、NaN/Infinity 的处理、struct tag 解析优先级都略有差异，线上替换前必须做字节级校验。
- 启用
json.UseNumber()后，go-json仍不支持json.Number的精确比较（标准库支持），会导致浮点字段校验失败 - 如果结构体含
time.Time且用json:"-"忽略，go-json可能仍尝试解析（取决于 tag 位置），而标准库严格遵循 struct tag - 基准测试时务必用相同输入数据、相同 target struct、相同
json.Unmarshal参数（如DisallowUnknownFields）横向对比
怎么让基准结果稳定，避开 Docker/K8s 环境干扰
容器环境下 CPU 频率缩放、cgroup 内存限制、NUMA 绑核缺失都会让 go test -bench 结果波动超 20%。尤其 json.Unmarshal 是内存密集型操作，对 NUMA node 跨访问敏感。
立即学习“go语言免费学习笔记（深入）”；
- 加
GOMAXPROCS=1和taskset -c 0锁定单核，排除调度抖动 - 用
go test -bench=. -benchmem -count=10 -benchtime=5s跑 10 轮取中位数，别信单次结果 - 在
/sys/fs/cgroup/memory/下确认当前进程没被限内存，否则大 JSON 会触发 OOM Killer 杀 benchmark 进程
真正卡住吞吐的往往不是反序列化函数本身，而是你没意识到 JSON 字段里混着 base64 编码的二进制 blob —— 它们被当成字符串反复拷贝，占掉 70% 时间。先用 jq '.field | length' 扫一遍字段长度分布，再决定要不要预处理。
