Go原生json性能瓶颈源于反射和interface{}处理；建议用导出字段+json tag、避免map[string]interface{}、优先定义具体类型，或用easyjson生成静态序列化代码。
Go 语言原生 json.Marshal 和 json.Unmarshal 在多数场景下够用，但高并发、大数据量或低延迟敏感服务里，它确实是性能瓶颈——不是写法错，是标准库设计目标本就不为极致性能。
为什么 json.Marshal 慢？关键在反射和 interface{} 处理
标准库 JSON 包对任意 interface{} 做序列化时，必须全程走反射：查字段名、判断类型、动态调用方法。哪怕你传的是结构体指针，只要没做类型断言或预编译，它就无法跳过反射路径。
常见错误现象：cpu profile 显示大量时间花在 reflect.Value.Interface、json.typeFields；QPS 上不去但 CPU 利用率卡在 70%+，GC 频次明显升高。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 避免直接传
map[string]interface{}或interface{}给json.Marshal，尤其在循环或高频接口中 - 结构体字段尽量用导出字段（首字母大写），并加
json:tag 控制行为，减少运行时推导 - 如果结构体固定且已知，优先定义具体类型，而非用泛型或
any接收后再转
用 easyjson 替代标准库：生成静态序列化代码
它不 runtime 反射，而是通过 easyjson 工具扫描结构体，生成专用的 MarshalJSON / UnmarshalJSON 方法。效果接近手写，但省去维护成本。
使用场景：微服务内部 DTO、API 响应结构稳定、需要压测达标（如 P99
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 安装：
go install github.com/mailru/easyjson/...@latest - 为结构体生成代码：
easyjson -all user.go，会产出user_easyjson.go - 调用时改用生成的方法：
User{}.MarshalJSON()而非json.Marshal(&u) - 注意：tag 语法兼容标准库，但不支持嵌套的
interface{}字段（会 panic），需提前 flatten
jsoniter 的 runtime 优化：兼容性好但需小心配置
它用 unsafe + 编译期常量折叠 + 类型缓存绕过部分反射，API 完全兼容标准库，替换成本最低。
性能差异主要来自两个配置项：jsoniter.ConfigCompatibleWithStandardLibrary（默认开启，安全但稍慢）和 jsoniter.ConfigFastest（关闭反射 fallback，快但遇到未知类型会 panic）。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 开发/测试阶段用兼容模式，上线前切到
ConfigFastest - 务必在启动时全局注册自定义类型：
jsoniter.RegisterTypeEncoder，否则 struct 字段仍可能触发反射 - 别在 hot path 中反复创建
jsoniter.API实例，复用一个全局变量 - 注意：它对
time.Time默认序列化为纳秒时间戳，和标准库不同，容易引发前端解析失败
什么时候不该动 JSON 性能？警惕过早优化
如果你的接口平均响应在 20ms 以上，瓶颈大概率不在 JSON 序列化——可能是 DB 查询、HTTP client 超时、锁竞争或日志打太多。
实操判断方式：
- 先跑一次
go tool pprof http://localhost:6060/debug/pprof/profile，看json.Marshal是否进前 3 热点 - 用
go test -bench=.对比前后，提升低于 15%，通常不值得引入新依赖 - 若服务已用 gRPC 或 Protocol Buffers，JSON 仅用于管理接口，优化优先级应大幅降低
真正难的不是换库，是确认「这里确实值得换」——很多团队花三天接入 easyjson，结果发现慢在一条没加索引的 SQL 上。
