性能优化核心是精简中间件链、前置静态路由、复用对象及正确配置连接池。冗余中间件降低吞吐5%–10%，gin.new()替代default()，按需use()；静态路径须置于动态路径前；用sync.pool避免频繁堆分配；json解析用jsoniter；db和http客户端必须配池，否则高并发下资源耗尽。
中间件链越短越好，别在全局Use()里塞一堆东西
每个中间件都会增加一次函数调用和栈帧开销，高频接口上多一个 Logger() 或 Recovery() 就可能吃掉 5%–10% 的吞吐。生产环境里，gin.Default() 默认带的两个中间件（日志 + panic 恢复）对压测或核心支付路径来说往往是冗余的。
- 把
gin.New()当默认起点，只在真正需要的地方显式Use() - 按路由组加载：比如
/api/internal/health这类探针接口，完全不需要鉴权中间件 - 避免在中间件里做 JSON 解析、DB 查询等同步阻塞操作；真要查，也得设超时，比如
ctx.WithTimeout(200 * time.Millisecond)
路由定义顺序影响匹配效率，静态路径必须放前面
Gin 的 Radix 树匹配本身很快，但动态参数（如 /users/:id）会触发更复杂的节点遍历。如果 /users/admin 和 /users/:id 同时存在，而后者注册在前，Gin 会优先匹配通配规则，导致前者永远不被命中——这不是 bug，是匹配逻辑决定的。
- 静态路径（如
/health、/metrics）写在最前 - 高频接口尽量用精确路径，少嵌套
Group("/v1").Group("/order")，直接api.GET("/v1/orders", ...)更快 - 避免在路径里混用通配符和正则，比如
/:id/:action，这种结构会让树深度变大，匹配耗时上升
sync.Pool 复用对象，别让每次请求都 new struct
频繁堆分配是 GC 压力的主要来源。一个典型场景：每个请求都 new 一个 map[string]interface{} 做响应封装，或每次解析 JSON 都创建新 bytes.Buffer，QPS 上去后 GC 频次飙升，STW 时间拉长。
- 对固定结构体（如分页响应模板）建
sync.Pool，New 函数返回指针，用完后Put() - JSON 解析推荐用
jsoniter.ConfigCompatibleWithStandardLibrary替代原生encoding/json，它内部已做缓冲池优化 - 字符串拼接别用
+，用strings.Builder；构建 URL 参数时也优先用url.Values而非手动拼接
数据库连接和 HTTP 客户端必须配池，别裸写 dial
没配连接池的 sql.Open() 或 http.Client 在高并发下会迅速耗尽文件描述符，出现大量 dial tcp: lookup xxx: no such host 或 too many open files 错误，不是代码慢，是系统资源卡死了。
-
db.SetMaxOpenConns(20)和db.SetMaxIdleConns(10)是底线配置，根据压测结果调；PostgreSQL 建议MaxOpenConns≤ 实例 CPU 核数 × 4 -
http.Client必须设Transport，尤其MaxIdleConnsPerHost（建议 ≥ 100）和IdleConnTimeout（建议 30s） - 第三方 API 调用别用全局
http.DefaultClient，它没设超时也没池，容易拖垮整个服务
实际压测中，去掉冗余中间件 + 静态路由前置 + sync.Pool 缓存响应结构体，往往就能把 QPS 拉高 2–3 倍；但连接池配置不对，再怎么优化代码也扛不住 1000+ 并发。很多人卡在最后一步——以为性能问题是框架或代码写的不够“炫”，其实只是漏配了 db.SetMaxIdleConns。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
