推荐用 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 不是银弹，压缩/解压耗时可能抵消网络节省，尤其移动端弱网下更需权衡。
