Go中真正可用的HTTP请求日志中间件需自定义ResponseWriter捕获状态码、显式记录时间、解析X-Forwarded-For获取真实IP、结构化输出，且必须置于最外层；仅用log.Printf会漏状态码、耗时不准、IP错误、格式混乱、阻塞高并发。
Go 中记录 HTTP 请求日志，核心是用中间件包装 http.Handler，再配合自定义 ResponseWriter 捕获状态码和耗时——不是加几行 log.Printf 就完事，否则会漏掉状态码、拿不到真实响应时间，甚至在高并发下拖慢服务。
怎么写一个真正可用的请求日志中间件
标准 http.ResponseWriter 不暴露状态码，直接调 w.WriteHeader() 无法感知；time.Since() 放在 defer 里还会因延迟执行导致耗时不准。必须自己封装。
- 用结构体嵌入原
ResponseWriter，重写WriteHeader()记录statusCode - 开始时间用
time.Now()显式记录，结束时间在next.ServeHTTP()后立刻取，再算差值 - 客户端 IP 要兼容反向代理（检查
X-Forwarded-For），否则所有请求都显示为网关地址 - 避免在日志里打印原始请求体或敏感头（如
Authorization），防止泄露凭证
func loggingMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
start := time.Now()
ip := r.RemoteAddr
if xff := r.Header.Get("X-Forwarded-For"); xff != "" {
ip = strings.TrimSpace(strings.Split(xff, ",")[0])
}
rw := &responseWriter{ResponseWriter: w, statusCode: http.StatusOK}
next.ServeHTTP(rw, r)
duration := time.Since(start)
log.Printf("method=%s path=%s ip=%s status=%d dur=%.2fms",
r.Method, r.URL.Path, ip, rw.statusCode, float64(duration.Microseconds())/1000)
})
}
type responseWriter struct {
http.ResponseWriter
statusCode int
}
func (rw *responseWriter) WriteHeader(code int) {
rw.statusCode = code
rw.ResponseWriter.WriteHeader(code)
}
为什么不能只用 log.Printf 简单打点
看似能跑通，但线上出问题时根本没法查：状态码永远显示 200（因为没捕获真实写入值），耗时偏差大（defer 延迟执行），IP 全是 127.0.0.1（没处理代理头），日志格式混乱（无法被 Loki 或 Filebeat 解析）。
-
log.Printf是同步阻塞 I/O，在 QPS 上千时可能成为瓶颈 - 没有结构化字段，grep 和日志平台检索效率极低
- 错误日志混在访问日志里，无法单独告警或切分文件
- 没带 trace ID，一次请求跨多个 handler 就断链，排查时像盲人摸象
生产环境该用 slog 还是 zap
Go 1.21+ 自带 log/slog 已足够轻量可靠，无需强上 zap——除非你已有成熟生态或需要极致性能（比如百万级 QPS 的网关）。slog 默认支持 JSON 输出、属性过滤、多 handler 分发，且无第三方依赖。
- 用
slog.With()注入请求 ID、路径、方法等上下文，避免每个 log 都重复传 - 把访问日志和错误日志分别路由到不同
slog.Handler（如一个写文件，一个写 stderr） - 禁用开发环境才需要的堆栈（
slog.HandlerOptions.AddSource = false），减少开销 - 别用
slog.String("error", err.Error())，要用slog.Any("err", err)保留错误链
最常被忽略的一点：日志中间件必须放在所有业务 handler 最外层，且不能被其他中间件（比如 CORS、JWT 验证）包裹在内——否则一旦验证失败提前返回，日志就完全丢失。它得是第一个“看到”请求、最后一个“看到”响应的角色。
