c.JSON()在高频接口中拖慢QPS，因其内部调用encoding/json.Marshal，引发反射遍历、动态内存分配与频繁GC，实测GC pause占比超15%；gin.H等map类型序列化开销比固定struct高2–3倍。
为什么 c.JSON() 在高频接口里会拖慢 QPS
c.JSON(200, data) 内部调用 encoding/json.Marshal，每次都要反射遍历结构体字段、动态分配内存、拼接字节流。在每秒几百次请求的接口上，这会触发频繁 GC，实测 GC pause 占总耗时 15%+。更关键的是，gin.H 这类 map 类型无法被编译器优化，序列化开销比固定 struct 高 2–3 倍。
用 jsoniter 替换标准库并预热配置
直接替换 import 并全局复用配置，能避开反射、减少逃逸：
import "github.com/json-iterator/go" var json = jsoniter.ConfigFastest
- 别在 handler 里重复声明
jsoniter.Config{}，每次新建都多一次初始化开销 - 如果结构体字段固定（如
type UserResp struct { ID int `json:"id"` }），可提前用jsoniter.RegisterTypeEncoder注册自定义编码器 - 注意：启用
ConfigCompatibleWithStandardLibrary会回退到兼容模式，性能损失约 20%，除非必须和标准库行为一致才开
避免中间件或绑定层反复解码/编码
常见错误是多次调用 c.ShouldBindJSON 或在中间件里 c.Set("raw_body", body) 后又在 handler 里再解一次。正确做法是：
- 用
json.NewDecoder(c.Request.Body).Decode(&v)流式解码，不读全[]byte，内存峰值降 60% - 若需复用原始 body（比如鉴权 + 业务逻辑都需读），在第一个中间件里调用
c.Request.Body = ioutil.NopCloser(bytes.NewReader(buf))并缓存buf到 context - 别在中间件里调用
c.JSON返回错误 —— 改用c.AbortWithStatusJSON，它跳过部分封装逻辑
高频响应直接写 bytes，绕过 c.JSON 封装
对返回结构稳定的接口（如健康检查、固定格式状态码），用 c.Data 手动控制输出最省：
// 预计算好 bytes，全局只一份
var okBytes = []byte(`{"status":"ok"}`)
func healthz(c *gin.Context) {
c.Data(200, "application/json", okBytes)
}
- 对动态数据，用
sync.Pool复用bytes.Buffer或json.Encoder实例，避免每次 malloc - 别用
fmt.Sprintf拼 JSON 字符串 —— 容易注入、无类型校验、GC 更重 - 如果返回的是数组切片且长度可控，考虑用
json.Compact预处理后缓存，比运行时压缩快
真正卡住吞吐的往往不是框架本身，而是每个请求里那几毫秒的 JSON 分配和反射；把 c.JSON 当成兜底方案，而不是默认选择，才能压出 Gin 的真实性能。
