Golang如何提升API接口响应速度_Golang接口性能优化

推荐用 http.HandlerFunc 替代 Struct 方法以降低 CPU 开销，结合 jsoniter/easyjson 加速 JSON 序列化，合理配置数据库连接池，并谨慎启用 gzip 压缩。

用 http.HandlerFunc 替代 http.Handle + struct 方法能减少接口延迟

go 的 http.ServeMux 默认使用反射调用 struct 方法（如 (s *Server) HandleUser），每次请求都触发方法值包装和接口转换，实测在高并发下比直接函数多 8–12% 的 CPU 开销。更轻量的做法是把逻辑写成闭包或顶层函数：

// 推荐：无状态、可内联的 handler func userHandler() http.HandlerFunc {     return func(w http.ResponseWriter, r *http.Request) {         id := r.URL.Query().Get("id")         if id == "" {             http.Error(w, "missing id", http.StatusbadRequest)             return         }         // 直接查 DB 或 cache，不经过中间 struct         u, err := db.GetUserByID(id)         if err != nil {             http.Error(w, err.Error(), http.StatusNotFound)             return         }         json.NewEncoder(w).Encode(u)     } }

注意：若 handler 需共享配置（如 DB 句柄），用闭包捕获比传指针更安全；但别在闭包里捕获大对象（如整个 *sql.DB 实例没问题，捕获未清理的 map 或 channel 就容易泄漏）。

JSON 序列化慢？优先用 jsoniter 或预编译 easyjson 结构体

标准 encoding/json 在每次序列化时都做字段反射查找，对高频接口（如每秒上千次的用户列表）影响明显。jsoniter 兼容原生 API 且默认开启 fast-path，替换后通常快 1.5–2 倍；easyjson 更激进——它生成静态序列化代码，避免运行时反射，但要求结构体字段必须导出且带 json: tag。

• 用 jsoniter.ConfigCompatibleWithStandardLibrary 初始化一次，全局复用
• 避免在 handler 里反复调用 jsoniter.Unmarshal 解析大 payload，改用 io.LimitReader 控制 body 大小
• easyjson 生成的 MarshalJSON 不支持嵌套 Interface{}，遇到动态字段得手动处理

数据库查询卡顿？别只加索引，先确认 database/sql 连接池是否被耗尽

常见现象是接口 P95 响应时间突然跳到 2s+，但 DB 慢查询日志没记录——大概率是连接池 wait 超时。默认 db.SetMaxOpenConns(0)（不限制），但 db.SetMaxIdleConns(2) 太小，导致频繁新建/关闭连接。实际应按 QPS 和平均查询耗时估算：

立即学习“go语言免费学习笔记（深入）”；

// 示例：QPS=500，平均 DB 耗时 20ms → 理论并发连接 ≈ 500 × 0.02 = 10 // 所以设 MaxOpenConns=20（留余量），MaxIdleConns=10 db.SetMaxOpenConns(20) db.SetMaxIdleConns(10) db.SetConnMaxLifetime(60 * time.Second)

另外，别在事务里做 HTTP 调用或文件读写；rows.Scan 后立刻 rows.Close()，否则连接不会归还池中。

gzip 压缩开销比你想象的大，用 net/http/pprof 确认是否真需要

启用 gzip 后，CPU 使用率可能上涨 15–30%，尤其对小响应体（5KB）。验证方式很简单：

go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30 # 查看 top -cum -focus=gzip

生产环境建议只对 Content-Type 包含 application/json 或 text/html 的响应压缩，且设置最小长度阈值（如 1KB），用中间件控制：

func gzipMiddleware(next http.Handler) http.Handler {     return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {         if !strings.Contains(r.Header.Get("Accept-Encoding"), "gzip") {             next.ServeHTTP(w, r)             return         }         w.Header().Set("Content-Encoding", "gzip")         gz := gzip.NewWriter(w)         defer gz.Close()         // 只有写入 >1024 字节才真正压缩         gw := &gzipResponseWriter{Writer: gz, ResponseWriter: w, minSize: 1024}         next.ServeHTTP(gw, r)     }) }

gzip 不是银弹，压缩/解压耗时可能抵消网络节省，尤其移动端弱网下更需权衡。