gin.Default()并非安全启动，因默认的Logger和Recovery中间件在高并发下显著拖慢P99延迟；应按需初始化、分组注册中间件、避免阻塞操作、优化JSON序列化并务必用pprof定位真实瓶颈。
别以为 gin.Default() 就是“安全启动”
很多人一上来就写 r := gin.Default()，觉得这是官方推荐的“开箱即用”。但它默认挂了 Logger() 和 Recovery() 两个中间件——这两个在压测或高频接口里就是隐形吞吐杀手。
Logger 每次请求都格式化时间、方法、路径、状态码、耗时，还往 stdout 写；Recovery 虽然兜底 panic，但内部用了 recover() + 栈遍历，开销不小。生产环境若没做日志分级或异步落盘，它们会直接拖慢 P99 延迟。
正确做法是按需初始化：
- 开发调试期用
gin.New().Use(gin.Logger(), gin.Recovery())，方便观察 - 线上服务用
gin.New()，自己显式注册必要中间件（比如只在 API 组加 Auth） - 健康检查路由（如
/healthz）必须绕过所有中间件：r.GET("/healthz", func(c *gin.Context) { c.Status(200) })
中间件不是越多越稳，而是越少越快
常见错误是把限流、鉴权、日志、监控全塞进全局中间件链：r.Use(RateLimit(), Auth(), Logger(), Metrics())。结果每个请求哪怕只是访问 /static/logo.png，也得跑完全部逻辑。
Gin 的中间件执行是同步串行的，每多一层函数调用，就多一次栈帧分配和上下文拷贝。实测在 10K QPS 下，5 层中间件比 2 层平均多出 0.8ms 延迟。
真正该做的：
- 静态资源走
r.StaticFS("/static", http.Dir("./static"))，它自动跳过所有中间件 - 按业务域分组注册：
v1 := r.Group("/v1"); v1.Use(Auth()); v1.GET("/users", handler) - 避免在中间件里做 DB 查询、HTTP 调用等阻塞操作；真要查，必须带
context.WithTimeout()
c.JSON() 看似简单，其实是 GC 高频触发点
c.JSON(200, data) 表面干净，背后是标准库 encoding/json 的反射+堆分配：每次调用都 new map、new slice、new string，高频接口下 GC 次数飙升，P99 波动明显。
尤其当 data 是动态结构（比如 map[string]interface{}）时，反射开销更大，且无法被编译器优化。
可落地的替换方案：
- 固定结构体优先用
jsoniter.ConfigFastest替代标准 JSON，性能提升 30%+，且兼容原生 API - 高频响应直接预序列化为
[]byte，用c.Data(200, "application/json", bytes) - 频繁构造的小对象（如分页响应 wrapper）用
sync.Pool复用，避免逃逸到堆上
pprof 不开，等于闭眼调优
很多人看到 QPS 上不去，第一反应是“换框架”或“加机器”，但从不跑一次 go tool pprof。Gin 自身调度开销极低，90% 的瓶颈都在你写的 handler 里——可能是没设超时的 http.Get()、没配连接池的 db.QueryRow()、或是 goroutine 泄漏。
上线前必做三件事：
- 启用 pprof：
import _ "net/http/pprof"; go func() { http.ListenAndServe("localhost:6060", nil) }() - 压测时采集 CPU profile：
wget "http://localhost:6060/debug/pprof/profile?seconds=30" - 重点看 top3 函数：是不是卡在
runtime.gopark（goroutine 阻塞）、runtime.mallocgc（内存分配）、或某段 SQL 执行上
最常被忽略的是：pprof 数据必须在真实负载下采集。本地跑几个请求看不出问题，只有在 AB 或 wrk 压到 70% CPU 时，热点才真正暴露出来。
