生产环境 Gin 性能瓶颈90%源于配置失当：必须设为 gin.ReleaseMode、显式配置数据库连接池（SetMaxOpenConns/SetConnMaxLifetime）、按路由组精准挂载中间件、替换标准 JSON 为 jsoniter.ConfigFastest。
生产环境的 Gin 应用性能瓶颈，90% 不在框架本身，而在配置失当或默认行为未关闭。直接上结论：不改 GinMode、不调数据库连接池、不分离中间件挂载点，再好的代码也扛不住压测。
必须设为 gin.ReleaseMode
开发模式下 gin.Default() 会自动启用 Logger() 和 Recovery()，且禁用模板缓存、开启反射调试等——这些对线上服务全是负向开销。即使你手动删了中间件，gin.Mode() 仍影响底层行为（如错误堆栈生成、参数绑定日志）。
- 确认方式：启动后打印
gin.Mode()，必须是"release"，不是"debug"或空字符串 - 设置位置：在
gin.New()后立即调用gin.SetMode(gin.ReleaseMode)，或更早地通过环境变量GIN_MODE=release - 风险点：某些日志中间件依赖
gin.DebugMode做条件判断，切 mode 后可能静默失效，需显式检查
db.SetMaxOpenConns() 和 db.SetConnMaxLifetime() 必须显式调用
Go 的 *sql.DB 默认不限制最大连接数，也不清理老化连接。高并发时，大量 goroutine 卡在 db.GetConn() 等待连接，表现就是接口延迟陡增、P99 毛刺严重，但 CPU 和内存看起来正常。
-
db.SetMaxOpenConns(20)：根据实例规格和业务 QPS 调整，4 核 8G 云服务器通常设为 15–25 -
db.SetConnMaxLifetime(30 * time.Minute)：避免连接被数据库端 silent kill 导致后续 query 报"connection reset by peer" - 漏掉
SetMaxIdleConns()会导致空闲连接不复用，频繁建连；建议设为与MaxOpenConns相同值
中间件不能全局注册，要按路由组精准挂载
全局中间件（如 r.Use(AuthMiddleware(), Logger())）会让每个请求都执行完整链路，包括健康检查 /healthz、静态资源 /static/、甚至 OPTIONS 预检——这些路径本应毫秒级返回，却平白多出几毫秒函数调用和上下文复制开销。
- 健康检查走裸 handler：
r.GET("/healthz", func(c *gin.Context) { c.Status(200) })，不经过任何中间件 - 静态资源用
r.StaticFS("/static", http.Dir("./static"))，它自动跳过所有中间件 - 权限类中间件只挂到业务组：
v1 := r.Group("/api/v1").Use(AuthMiddleware()); v1.GET("/user", handler) - 日志中间件若必须全局，至少加路径过滤逻辑，跳过已知高频无意义路径
JSON 序列化必须换 jsoniter.ConfigFastest
c.JSON(200, data) 默认用标准库 encoding/json，它每次调用都做反射扫描结构体字段，高频接口（如每秒数百次用户查询）会显著抬高 GC 频率，pprof 显示 reflect.Value.MapKeys 或 runtime.mallocgc 占比异常高。
- 替换方式：定义全局变量
var json = jsoniter.ConfigFastest，然后用json.Marshal(data)+c.Data(200, "application/json", bytes) - 不要只改序列化，反序列化也要同步换：
json.Unmarshal(c.Request.Body, &v) - 注意：如果用了自定义
UnmarshalJSON方法，jsoniter默认不兼容，需加 tagjsoniter.RawMessage或显式注册解码器
真正卡住线上服务的，往往不是某段算法有多慢，而是几个“默认就开着”的开关没关——GinMode、数据库连接池、中间件作用域、JSON 库，这四点漏掉任意一个，压测数据就会和预期差一个数量级。调优不是加功能，是关掉不该开的东西。
