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 响应”。
立即学习“go语言免费学习笔记（深入）”；
- 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)） - 更稳妥的方案是只记录摘要（如
sha256hash）或关键字段（需先解析 JSON 再提取字段，而非 dump 全量）
真正难的不是“怎么打出日志”，而是平衡可观察性与性能损耗：记录太简略查不出问题，记录太全又拖慢接口、撑爆磁盘。生产环境建议按需开启——比如只对 5xx 响应或耗时 >1s 的请求做全量采样。
