Go HTTP访问日志中间件需用自定义responseWriter包装ResponseWriter，拦截WriteHeader和Write以准确记录状态码和响应体长度，并结合zap等结构化日志库实现高性能、可审计的日志输出。
Go HTTP 中间件怎么加访问日志
直接在 http.Handler 外包一层函数是最轻量、最可控的方式。Go 的 http.HandlerFunc 本身就是函数类型，天然适合链式中间件。不需要引入框架（如 Gin、Echo），原生 net/http 就够用。
关键点是：必须在调用 next.ServeHTTP() 前记录请求开始时间，之后读取 ResponseWriter 的状态码和响应体长度——但原生 http.ResponseWriter 不暴露写入字节数，得用包装器。
- 用自定义的
responseWriter结构体嵌套原始http.ResponseWriter，重写Write()和WriteHeader() - 在
WriteHeader()被调用时才确定最终状态码；若没显式调用，则默认200 - 响应体长度只统计
Write()写入的字节数，不包括 header 开销
如何避免日志里出现 0 状态码或 -1 字节数
常见错误是没等 handler 执行完就记录日志，或者忘记覆盖 WriteHeader() 导致状态码始终为 0。根本原因是：原生 ResponseWriter 的 Header() 和 WriteHeader() 是分离的，且 Write() 可能隐式触发 WriteHeader(http.StatusOK)。
- 务必在包装器中拦截
WriteHeader()，把传入的状态码存到字段里 -
Write()方法里要判断是否已写 header，未写则先调用rw.ResponseWriter.WriteHeader(http.StatusOK)再记录 - 不要依赖
http.Response或http.Request自带字段获取响应长度——它们压根不提供
日志格式该不该包含 User-Agent 和 Referer
取决于用途。如果是调试或安全审计，建议保留；如果是高吞吐服务（QPS > 1k），req.Header.Get("User-Agent") 和 req.Header.Get("Referer") 会触发字符串拷贝和内存分配，增加 GC 压力。
立即学习“go语言免费学习笔记（深入）”；
- 生产环境可默认关闭 UA/Referer，用配置开关控制是否采集
- 若需保留，建议用
strings.HasPrefix()或预编译正则做简单过滤（比如只记移动端 UA），避免全量记录 - 注意：
req.RemoteAddr可能是反向代理 IP，应优先读X-Forwarded-For，但必须校验可信代理列表，否则易被伪造
要不要用第三方日志库（如 zap）替代 fmt.Fprintf
要。原生 fmt.Fprintf 在高并发下性能差、无缓冲、无异步能力，单条日志可能阻塞整个请求流。zap 提供 Logger.WithOptions(zap.AddCaller(), zap.AddStacktrace(zap.WarnLevel)) 等实用能力，且结构化日志便于后续接入 ELK 或 Loki。
但注意迁移成本：
- 别直接把所有字段塞进
zap.String("msg", ...)，应拆成结构化字段：logger.Info("http request", zap.String("method", req.Method), zap.String("path", req.URL.Path), zap.Int("status", rw.status), zap.Int64("bytes", rw.bytes)) - 避免在中间件里新建
zap.Logger实例，应从外部传入或使用全局 logger - zap 的
Sync() -> Flush()需手动调用（尤其用文件写入时），否则可能丢日志
func loggingMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
start := time.Now()
rw := &responseWriter{ResponseWriter: w, status: http.StatusOK}
next.ServeHTTP(rw, r)
duration := time.Since(start)
logger.Info("http request",
zap.String("method", r.Method),
zap.String("path", r.URL.Path),
zap.Int("status", rw.status),
zap.Int64("bytes", rw.bytes),
zap.Duration("duration", duration),
zap.String("ip", getRealIP(r)),
)
})
}
type responseWriter struct {
http.ResponseWriter
status int
bytes int64
}
func (rw *responseWriter) WriteHeader(statusCode int) {
rw.status = statusCode
rw.ResponseWriter.WriteHeader(statusCode)
}
func (rw *responseWriter) Write(b []byte) (int, error) {
if rw.status == 0 {
rw.status = http.StatusOK
}
n, err := rw.ResponseWriter.Write(b)
rw.bytes += int64(n)
return n, err
}
日志中间件真正的复杂点不在代码行数，而在于：状态码捕获时机、响应体长度统计精度、真实客户端 IP 的可信提取、以及结构化日志字段命名的一致性——这些地方一旦出错，排查时会浪费大量时间在“以为记了其实没记”上。