先关掉 gin.DebugMode：它默认开启，会触发彩色日志、路由校验、中间件栈 dump，实测 QPS 直跌 40%+，影响远超框架差异；必须显式设为 gin.ReleaseMode 并确认生效。
压测 QPS 上不去？先关掉 gin.DebugMode
真实业务中，gin.DebugMode 是压测阶段最常被忽略的性能开关。它默认开启（只要环境变量 GIN_MODE 不是 release），会触发三类高开销行为：打印彩色日志、校验路由重复注册、每次请求都做中间件栈 dump。实测在 M2 芯片上，开启状态下 wrk -t4 -c100 -d30s 的 QPS 直接跌 40%+，比换框架影响更大。
必须显式关闭：
func main() {
gin.SetMode(gin.ReleaseMode) // 或 os.Setenv("GIN_MODE", "release")
r := gin.New()
// ...
}
- 别依赖
.env文件或启动脚本隐式设置，压测前用fmt.Println(gin.Mode())确认值为release - CI/CD 构建镜像时，确保基础镜像没带调试环境变量（比如某些 alpine-golang 镜像默认设了
GIN_MODE=debug） - 如果你用
gin.Default()，它内部会调用gin.New()+Logger()+Recovery()，而Logger()在 debug 模式下会同步写 stdout，阻塞 goroutine
响应延迟高？检查中间件顺序和 c.Next() 是否漏写
线上 500 错误或静默失败，80% 出在中间件链执行逻辑上。Gin 的 c.Next() 不是“继续往下走”，而是“把控制权交还给上一层中间件”，漏写或错放位置会导致整个 handler 链中断。
-
Recovery()必须放在所有可能 panic 的中间件之后——如果它在AuthMiddleware()前面，panic 发生后 Recovery 已写响应头，Auth 根本没执行，权限校验形同虚设 - 子路由组里重复注册同一中间件（如两次
group.Use(AuthMiddleware())），会导致鉴权被绕过两次，且第二次c.Request可能为 nil，引发空指针 panic - 调试时注释掉某中间件但忘了删
c.Next()，运行时 panic 报错：runtime error: invalid memory address or nil pointer dereference
建议在关键中间件开头加防御性判断：
func AuthMiddleware() gin.HandlerFunc {
return func(c *gin.Context) {
if c.Request == nil {
c.AbortWithStatusJSON(500, gin.H{"error": "request is nil"})
return
}
// ...
}
}
内存暴涨、GC 频繁？别在 handler 里直接 c.JSON() 大量数据
c.JSON(200, hugeSlice) 看似简洁，但会触发三重压力：一次 json.Marshal 全量序列化（CPU）、一次大内存分配（heap）、一次完整响应体拷贝（net/http 内部）。当 hugeSlice 含上万条记录时，单次请求可能分配数 MB，GC 压力陡增，P99 延迟跳变。
- 优先分页：用
db.Offset().Limit()控制单次返回数量，前端按需拉取 - 流式响应：对导出类接口，改用
c.Stream()+json.NewEncoder(c.Writer).Encode()，避免全量内存驻留 - 替换序列化器：用
json-iterator/go替代标准库，实测吞吐提升近 2 倍；极端场景可上simdjson（需 CGO），耗时从 12.3μs 降至 2.1μs
别信“Go 自动优化”，encoding/json 的反射路径在大数据量下就是瓶颈，这点在 pprof 的 CPU profile 里一眼可见。
为什么 pprof 显示 runtime.mallocgc 占比高？查 sync.Pool 是否复用到位
Gin 本身已用 sync.Pool 复用 *gin.Context，但业务代码里大量新建结构体（如 UserData{}、Response{}）仍会高频触发 GC。尤其在中间件中反复解析 token、解密 payload 时，对象创建不可控。
- 对高频使用的结构体，自己建
sync.Pool：比如var userPool = sync.Pool{New: func() interface{} { return &UserData{} }} - 避免在 handler 中用
make([]byte, n)分配大 buffer，改用预分配池或bytes.Buffer复用 - 注意 Pool 对象生命周期：不能存闭包、不能存指针到栈变量，否则引发 data race
真正卡住性能的，往往不是框架选型，而是这些“写起来顺手、跑起来吃力”的细节。上线前跑一次 go tool pprof http://localhost:6060/debug/pprof/heap，看 top3 分配来源，比读十篇框架对比文章更管用。
