如何优化Golang网络请求序列化性能_Golang net/http序列化优化方法_技术教程

json.Marshal在HTTP handler中成瓶颈，因每次响应都反射序列化且无法复用缓冲区；改用json.Encoder直接写入响应流可提升QPS 15%–30%，内存分配减90%以上。

为什么 `json.Marshal` 在 HTTP handler 中成为瓶颈

Go 的 net/http 默认不缓存序列化结果，每次响应都调用 json.Marshal —— 这个操作在结构体字段多、嵌套深或并发高时会明显拖慢吞吐。更关键的是，json.Marshal 会反复反射遍历结构体字段，即使数据内容不变，只要类型未被提前注册，开销就无法避免。

字段含指针、interface{} 或自定义 marshaler 时，反射成本进一步上升
大量小对象高频返回（如 API 列表页）比单次大对象更易暴露问题
http.ResponseWriter 是接口，无法直接复用底层 []byte 缓冲区，每次都要新分配

用 `json.Encoder` 替代 `json.Marshal` 直接写入响应流

避免中间 []byte 分配和拷贝，让序列化结果直接流向客户端连接缓冲区。这对中等以上体积响应（>1KB）效果显著，实测 QPS 可提升 15%–30%，内存分配次数减少 90% 以上。

func handler(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Content-Type", "application/json")
    enc := json.NewEncoder(w)
    // 不要再做 data, _ := json.Marshal(v); w.Write(data)
    if err := enc.Encode(v); err != nil {
        http.Error(w, err.Error(), http.StatusInternalServerError)
        return
    }
}

注意：必须确保 w 尚未写入任何内容，否则 Encode 可能 panic（如已调用 w.WriteHeader 但未写 body）
若需控制状态码且依赖 Encode 成功后再写头，可先写 http.StatusOK，再调用 Encode
json.Encoder 内部会复用缓冲区，但不会跨请求复用；它不解决反射开销，只优化内存路径

预编译结构体 JSON 元信息：用 `jsoniter.ConfigCompatibleWithStandardLibrary` + `RegisterType`

标准库 json 包每次 Marshal 都重新计算字段顺序、tag 解析、类型检查。用 jsoniter 并显式注册类型，可跳过运行时反射，把元信息固化到内存中。

var jsonAPI = jsoniter.ConfigCompatibleWithStandardLibrary.
    WithNumber().
    Froze()

func init() {
    jsonAPI.RegisterTypeEncoder(reflect.TypeOf(MyStruct{}), myStructEncoder{})
}

func handler(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Content-Type", "application/json")
    jsonAPI.NewEncoder(w).Encode(v) // 此处不再触发反射扫描
}