Go微服务JSON序列化慢的主因是标准库encoding/json在高频固定结构场景下存在反射和内存分配开销；应优先采用easyjson预生成编解码器或json-iterator/go替换，辅以流式写入和结构体优化。
Go微服务里JSON序列化慢，不是写法问题，是标准库encoding/json在高频、固定结构场景下天然有反射和内存分配开销。直接换库或改用预生成代码，比调参数更有效。
为什么json.Marshal在微服务里特别拖后腿
微服务接口通常结构稳定、调用量大，但encoding/json每次调用都要走反射查字段、动态判断类型、拼接键值对——这些操作在QPS上万时会明显卡住CPU，profile里常看到reflect.Value.Interface和json.typeFields占大量时间。同时，每个请求都新建[]byte和map，GC压力飙升，P99延迟跳变。
- 别在HTTP handler里直接
json.Marshal(&resp)，尤其当resp含map[string]interface{}或深层嵌套结构体 -
omitempty标签虽省体积，但运行时要逐字段判空，字段越多越拖慢；真要省带宽，不如前置过滤字段 - 时间字段别依赖
time.Time默认序列化，RFC3339格式字符串解析开销大，且前端兼容性差
用easyjson生成静态编解码器
对DTO、响应结构体这类长期不变的类型，easyjson能彻底绕过反射。它扫描源码生成MarshalJSON/UnmarshalJSON方法，性能接近手写，且保留json:标签语义。
- 结构体上方加
//easyjson:json注释，再运行easyjson -all user.go生成user_easyjson.go - 调用时改用
u.MarshalJSON()而非json.Marshal(&u)，注意传值还是传指针要和生成逻辑一致 - 不支持
interface{}字段，遇到就panic；必须提前flatten，比如把map[string]interface{}拆成具体字段 - 生成文件必须和源码一起编译，漏掉会导致运行时仍走标准库反射路径
流式写入替代json.Marshal + Write
HTTP响应、gRPC网关、日志推送等场景，没必要先把整个JSON塞进内存再写出去。json.Encoder直接写到io.Writer，零中间分配，还能配合http.Flusher做SSE。
用于端到端视频本地化流程的轻量编排器，路由至四个专注子技能——/wjs-transcribing-audio、/wjs-translating-subtitles...
立即学习“go语言免费学习笔记（深入）”；
- 用
json.NewEncoder(w).Encode(resp)代替data, _ := json.Marshal(resp); w.Write(data) -
w要是http.ResponseWriter，确保没提前写header，否则Encode会panic - 别在循环里反复创建
json.Encoder，复用一个实例或从sync.Pool取；它的内部缓冲区可重置复用 - 对大数组，用
json.Encoder逐个Encode元素，比先构造slice再Marshal省内存
json-iterator/go无缝替换但配置要小心
API完全兼容标准库，只需改导入路径，适合快速落地。但它有两个关键配置开关：默认走兼容模式（安全但慢），上线前必须切到ConfigFastest才能发挥性能优势。
- 全局初始化一次：
jsoniter.ConfigFastest.MarshalToString返回的API实例复用，别每次new - 务必注册自定义类型：
jsoniter.RegisterTypeEncoder("time.Time", ...)，否则time.Time字段仍触发反射 - 它默认把
time.Time序列化为纳秒时间戳，和标准库RFC3339不一致，前端可能解析失败 - 不处理
json.RawMessage的延迟解析逻辑，如果靠它跳过复杂结构，得自己补UnmarshalJSON
真正卡性能的往往不是JSON本身，而是没意识到json.Marshal的反射成本藏在每一层结构体嵌套里——哪怕字段只有5个，只要用了interface{}或map，就退回到最慢路径。微服务优化优先级：固定结构 → 生成代码 → 流式写入 → 换库，别一上来就折腾sync.Pool缓存缓冲区。
