json.Marshal在微服务中慢因每次调用均需反射查字段、解析标签、检查nil、UTF-8转义及字节拼接，高频嵌套结构与interface{}加剧开销；easyjson通过编译期生成无反射代码可提升吞吐3–5倍、减少GC 90%+。
为什么 json.Marshal 在微服务里特别慢
不是标准库本身烂，而是它在每次调用时都得做一整套“安全但啰嗦”的事：反射查字段、解析 json: 标签、检查指针是否为 nil、对字符串做 UTF-8 转义（比如把 " 变成 \"）、逐个拼接字节。微服务里接口高频、结构体嵌套深、还常带 map[string]interface{} 或 interface{} 字段——这些全是反射重灾区。pprof 里 reflect.Value.Interface 和 encoding/json.(*encodeState).marshal 占 CPU 30%+ 是常态。
用 easyjson 生成无反射代码（最稳的提速点）
它不改你的框架、不换 HTTP 库，只给结构体加一行注释，就能把序列化路径从运行时反射变成编译期生成的纯字段访问 + strconv.AppendInt 拼接。实测吞吐提升 3–5 倍，GC 分配减少 90%+。
-
//easyjson:json必须独占一行，写在结构体定义上方 - 结构体字段必须导出（首字母大写），且带明确
json:标签，比如ID int `json:"id"` - 别在生成结构体里嵌套未生成的匿名 struct；也别用
interface{}字段，否则 easyjson 生效不了 - 生成命令：
easyjson -all user.go，会产出user_easyjson.go，里面是可读性尚可的手写级代码 - Gin/Echo 等框架仍用
c.ShouldBindJSON(&v)，只要v类型实现了生成的UnmarshalJSON，就自动走优化路径
复用 json.Encoder 和缓冲区（别让每次请求都 malloc）
框架默认每请求新建 json.Encoder，内部缓冲区反复分配。尤其在流式响应或 WebSocket 场景下，这是硬伤。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 用
sync.Pool缓存json.Encoder实例，Encoder.DisableHeaderCheck(true)可跳过一次 header 判断 - 预分配
bytes.Buffer并复用：buf := bufferPool.Get().(*bytes.Buffer); buf.Reset() - 别把整个 request body 读成
[]byte再传给json.Unmarshal——改用json.NewDecoder(c.Request.Body)直接流式解码，内存峰值降 60% - 对批量响应，循环中复用同一个
Encoder，比反复调用json.Marshal少 70%+ 分配
jsoniter 替换标准库（兼容性优先的折中方案）
它是个 drop-in 替代，只需两行代码切换，适合不想动结构体定义、又急需性能提升的场景。但它不是银弹：首次加载仍有反射开销，且某些边界行为（如 MarshalJSON 调用顺序）和标准库不完全一致。
立即学习“go语言免费学习笔记（深入）”；
- 导入替换：
import jsoniter "github.com/json-iterator/go"，再用jsoniter.ConfigCompatibleWithStandardLibrary - 禁用 HTML 转义：
jsoniter.Config{EscapeHTML: false}能省掉<→\u003c的处理，吞吐提 5%–10% - 别在
init函数里反复创建新配置实例——复用单例，否则 GC 压力反升 - 对含大量字符串字段的结构体，
jsoniter效果明显；但若已有easyjson生成结构体，再套一层jsoniter不仅没增益，还可能引入额外封装开销
真正卡住性能的往往不是某一个技巧，而是多个低效点叠加：结构体里混着 interface{}、字段标签写成 json:"user_name"（触发字符串匹配）、每次响应都 new 一个 bytes.Buffer、又没关 EscapeHTML。先跑一次 pprof，看 encoding/json 占多少 CPU 和 mallocgc 调用次数，再决定从哪下手。
