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) // 此处不再触发反射扫描
}
- 必须在
init()或服务启动早期注册，否则首次调用仍会走慢路径 - 仅对固定结构体有效；含
map[string]interface{}或interface{}字段的场景无法完全规避反射 - 注意
jsoniter的Froze()调用不可少，否则注册无效
HTTP 响应体复用：对稳定响应内容启用 sync.Pool 管理编码后字节切片
当某些响应内容几乎不变（如配置接口、静态元数据），可预先序列化一次，之后从池中获取复用。适用于读多写少、内容生命周期长的 endpoint。
立即学习“go语言免费学习笔记（深入）”；
- 不要直接池化
json.Marshal结果——需保证并发安全，且需手动管理失效逻辑 - 更稳妥的做法是池化
*bytes.Buffer或[]byte，并在 handler 中重置后写入新数据 - 若内容随请求参数微调（如分页 offset），则池化收益急剧下降，此时应优先考虑
Encoder+ 预注册
真正难处理的是那些字段动态拼装、嵌套深度不确定、又要求低延迟的响应——这时候序列化本身不是唯一瓶颈，得回头检查数据组装逻辑是否可裁剪或延迟计算。
