Go微服务JSON序列化慢的核心瓶颈是encoding/json强依赖反射，每次调用需查字段、读标签、判nil、转义字符串、拼接字节，pprof中reflect.Value.Interface等函数常占CPU 30%+；easyjson通过编译期生成无反射代码（如u.MarshalJSON()）可提升吞吐3–5倍、减少GC 90%+，并需避免interface{}字段、正确使用//easyjson:json注释及复用json.Encoder实现零中间分配。
Go 微服务里 JSON 序列化慢，核心瓶颈不在网络或框架，而在 encoding/json 对反射的强依赖——每次调用都得查字段、读标签、判 nil、转义字符串、拼接字节，这些操作在 QPS 上万时直接吃掉 30%+ CPU。
为什么 reflect.Value.Interface 在 pprof 里总占高位
这不是偶然，是标准库序列化路径的必然结果：json.Marshal 内部大量调用 reflect.Value.Interface() 和 reflect.Value.FieldByName()，而这两个函数本身开销就大：
-
reflect.Value.Interface()每次都要做接口转换 + 类型检查 + 堆分配临时结构体 -
FieldByName()是线性遍历，100 字段的 struct 就比 100 次字符串相等 - 嵌套结构体、
map[string]interface{}、interface{}字段会让反射深度和分支数指数级增长 - 字段带
omitempty标签？运行时还得逐个调IsNil()或Len() == 0
easyjson 生成代码为何能绕过反射
它不运行时查，而是在编译前就把字段偏移、类型、标签全算死，生成纯字段访问 + strconv.AppendInt / append 拼接的代码：
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 结构体必须导出（首字母大写），且每个字段带明确
json:标签，比如ID int `json:"id"` -
//easyjson:json注释必须独占一行，写在结构体定义正上方 - 生成命令：
easyjson -all user.go，产出user_easyjson.go，里面没有reflect包引用 - 调用时改用
u.MarshalJSON()，不是json.Marshal(&u)；传值还是传指针要和生成逻辑一致（默认按指针生成） - 不支持
interface{}字段——遇到就 panic，得提前 flatten 成具体字段
复用 json.Encoder 为什么比缓存 reflect.Type 更立竿见影
缓存 reflect.Type 能省一点查表开销，但解决不了内存分配问题；而 json.Encoder 复用直接砍掉每请求一次 bytes.Buffer 分配 + GC 压力：
立即学习“go语言免费学习笔记（深入）”；
- 别在 handler 里写
data, _ := json.Marshal(resp); w.Write(data)—— 这等于把整个响应塞进内存再吐出去 - 改用
json.NewEncoder(w).Encode(resp)，数据边序列化边写入io.Writer，零中间分配 - 用
sync.Pool缓存*json.Encoder实例，调用前enc.Reset(w)即可重置输出目标 - 预分配
bytes.Buffer并复用：buf := bufferPool.Get().(*bytes.Buffer); buf.Reset() - 对批量响应（如数组流式推送），循环中复用同一个
Encoder，比反复json.Marshal少 70%+ 分配
真正卡住微服务吞吐的，往往不是算法复杂度，而是那些看似“安全”的默认行为：每次反射查字段、每次新建缓冲区、每次把 interface{} 当万能解药。绕过反射不是为了炫技，是让 CPU 时间花在业务逻辑上，而不是在类型表里翻来覆去地找字段名。
