Go 的 HTTP 日志需自定义 responseWriter 获取状态码和字节数，优先取 X-Forwarded-For 获取客户端 IP，避免直接读取 Body 导致下游解析失败，生产环境应结构化异步记录并按需采样。

Go 的 http.ServeMux 和 http.Handler 本身不记录请求日志，必须手动注入中间件或包装 http.Handler；直接用 log.Printf 打印基础信息容易丢失上下文（如响应状态码、耗时、请求体），也不方便结构化存储。

用 http.HandlerFunc 包装 handler 实现基础请求日志

最轻量的方式是写一个日志中间件函数，接收原始 http.Handler 并返回包装后的 http.Handler。关键点在于：必须在 WriteHeader 和 Write 被调用后才能获取真实状态码和响应字节数，所以需自定义 http.ResponseWriter 实现。

• 不能只靠 r.Method + r.URL.Path 就打日志——漏掉查询参数、请求头、客户端 IP
• 客户端 IP 应优先取 X-Forwarded-For（若服务在反向代理后）， fallback 到 r.RemoteAddr
• 响应体内容一般不记录（性能/隐私），但可记录长度：written 字段来自自定义 responseWriter 的 Write 方法计数

type loggingResponseWriter struct {
	http.ResponseWriter
	statusCode int
	written    int
}

func (lrw *loggingResponseWriter) WriteHeader(code int) {
	lrw.statusCode = code
	lrw.ResponseWriter.WriteHeader(code)
}

func (lrw *loggingResponseWriter) Write(b []byte) (int, error) {
	if lrw.statusCode == 0 {
		lrw.statusCode = http.StatusOK
	}
	n, err := lrw.ResponseWriter.Write(b)
	lrw.written += n
	return n, err
}

func loggingMiddleware(next http.Handler) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		start := time.Now()
		lrw := &loggingResponseWriter{
			ResponseWriter: w,
			statusCode:     0,
		}

		next.ServeHTTP(lrw, r)

		clientIP := r.Header.Get("X-Forwarded-For")
		if clientIP == "" {
			clientIP = strings.Split(r.RemoteAddr, ":")[0]
		}

		log.Printf("[%s] %s %s %s %d %d %v",
			time.Now().Format("2006-01-02 15:04:05"),
			clientIP,
			r.Method,
			r.URL.Path,
			lrw.statusCode,
			lrw.written,
			time.Since(start),
		)
	})
}

用 net/http/httputil.DumpRequestOut 记录完整请求（仅调试）

生产环境禁用——httputil.DumpRequestOut 会读取并缓冲整个 Body，导致后续 handler 无法再读；且明文打印敏感字段（如 Authorization、Cookie）。

• 仅限本地开发或临时排查，且必须加条件开关（如环境变量 LOG_FULL=1）
• 调用前需确保 r.Body 可重放：用 io.NopCloser(bytes.NewReader(buf)) 替换原 body
• 务必过滤敏感 header：Authorization、Cookie、X-API-Key 等应替换为 [REDACTED]

对接结构化日志系统（如 zap + file rotation）

用 go.uber.org/zap 替代 log 包，能输出 JSON 格式日志，便于 ELK 或 Loki 收集。重点不是“怎么打日志”，而是“怎么避免日志拖慢 HTTP 响应”。

• zap 的 Info 调用本身很快，但磁盘 I/O 是瓶颈——必须用异步写入（zap.NewProductionConfig().EncoderConfig.EncodeLevel = zapcore.CapitalLevelEncoder + zap.AddCaller()）
• 文件轮转需用 lumberjack.Logger，而非自己拼接时间戳命名——否则并发写入时可能丢日志
• 不要为每个请求都 Open/Close 日志文件；初始化一次，全局复用 *zap.Logger

注意 http.Request.Body 的一次性读取特性

很多开发者想在日志里记录请求体（比如 JSON payload），结果发现 handler 里 io.ReadAll(r.Body) 后，下游解析失败。根本原因是 r.Body 是单次读取流。

• 正确做法：用 io.TeeReader 把 body 流同时写入 buffer 和传递给原 handler
• 但要注意内存——大文件上传场景下，buffer 可能 OOM；建议限制最大读取长度（如 io.LimitReader(r.Body, 1024*1024)）
• 更稳妥的方案是只记录摘要（如 sha256 hash）或关键字段（需先解析 JSON 再提取字段，而非 dump 全量）

真正难的不是“怎么打出日志”，而是平衡可观察性与性能损耗：记录太简略查不出问题，记录太全又拖慢接口、撑爆磁盘。生产环境建议按需开启——比如只对 5xx 响应或耗时 >1s 的请求做全量采样。