HTTP 处理函数中应避免同步阻塞操作,所有 I/O 必须带 context;合理配置数据库连接池;静态资源用 FileServer 流式传输;日志需结构化、缓冲并按需输出;中间件复用对象、避免反射;模板和静态文件需预热与缓存。
Go 的 http.ServeMux 默认为每个请求启动一个 goroutine,但若你在 http.HandlerFunc 里调用 time.Sleep、大文件读取、未加 context 控制的数据库查询或第三方 API 同步调用,会直接卡住该 goroutine,浪费调度资源且拖慢整体吞吐。
实操建议:
context.Context,并在 handler 入口传入 r.Context()
database/sql 时确保连接池已合理配置:db.SetMaxOpenConns(20)、db.SetMaxIdleConns(10),避免默认无限增长耗尽 DB 连接os.ReadFile 加载大静态资源;改用 http.ServeFile 或 http.FileServer,它们内部使用 io.Copy 流式传输,不全量加载进内存log.Printf 和未缓冲的结构化日志高频请求下,每请求打一条 log.Printf("req: %s, status: %d", r.URL.Path, statusCode) 会导致大量系统调用和字符串拼接,成为性能瓶颈。尤其当日志输出到磁盘或远程服务时,延迟更明显。
实操建议:
log.Printf,改用轻量级结构化日志库(如 zerolog 或 zap),并启用 zerolog.NewConsoleWriter() 的 Buffered: true 选项if cfg.Debug { logger.Debug().Str("path", r.URL.Path).Send() }
*http.Request),而应提取必要字段(r.Method, r.URL.Path, r.Header.Get("User-Agent"))常见中间件如 JWT 验证、请求 ID 注入、CORS 处理,若每次请求都新建 map、调用 json.Unmarshal、或用 reflect.ValueOf 做泛型处理,会在 GC 周期带来明显压力。
实操建议:
sync.Pool 缓存临时对象,例如解析 JWT token 后的 map[string]interface{} 可用池管理golang-jwt/jwt/v5 的 ParseWithClaims + 预定义 struct,避免 map[string]interface{} 的动态解码开销r.Header.Set 替代 r.Header = cloneHeader(r.Header) 这类深拷贝逻辑var headerPool = sync.Pool{
New: func() interface{} {
return make(http.Header)
},
}
func withRequestID(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
h := headerPool.Get().(http.Header)
defer headerPool.Put(h)
id := r.Header.Get("X-Request-ID")
if id == "" {
id = uuid.New().String()
}
h.Set("X-Request-ID", id)
r.Header = h // 注意:仅适用于只读场景;若下游修改 Header,需另作处理
next.ServeHTTP(w, r)
})
}
首次访问 HTML 模板时,html/template.ParseFiles 会编译 AST 并缓存,但若每次请求都重新 Parse,不仅慢还会泄漏内存。同理,CSS/JS 若由后端动态生成且无缓存头,CDN 和浏览器都无法复用。
实操建议:
ParseFiles 或 ParseGlob,全局复用 *template.Template 实例,绝不在 handler 中重复 parseCache-Control: public, max-age=31536000(一年),并用 http.FileServer + http.StripPrefix,而非自己读文件再 write
动态注入变量(如 CSRF Token)到 HTML,用 template.Execute 而非字符串拼接,且确保传入的数据是已序列化的基础类型(string, int, bool),避免传入含方法的 struct 触发反射