必须用支持并发与缓冲的日志库（如zap）替代标准log，记录method、path、status、duration_ms、remote_ip、user_agent等结构化字段，配合lumberjack轮转和异步写入，并正确解析真实IP。
用 log 包直接写 HTTP 请求日志会丢数据
Go 标准库的 log 默认输出到 os.Stderr，且无缓冲控制和并发保护。在高并发 Web 场景下，多个 goroutine 同时调用 log.Println 可能导致日志行错乱、截断甚至丢失。
- 避免直接在
http.HandlerFunc里用log.Printf打请求日志 - 必须加锁或改用支持并发写入的日志库（如
zap、zerolog） - 若坚持用标准库，至少将输出重定向到带缓冲的
os.File，并设置log.SetOutput
中间件里记录结构化请求日志的关键字段不能少
HTTP 日志不是记“谁访问了”，而是要支撑问题定位：响应时间、状态码、路径参数、客户端 IP、User-Agent、错误上下文都得有。裸字符串拼接难解析，建议用结构体序列化为 JSON。
- 必采字段：
method、path、status、duration_ms、remote_ip（注意 X-Forwarded-For 处理）、user_agent - 推荐用
time.Now()记开始时间，defer算耗时，别依赖ResponseWriter的 Hook（它不保证执行） - 不要在日志里打印完整
body—— 有安全与性能风险；如需调试，单独加开关控制
zap 配合 gin 或 net/http 的最小可行日志中间件
zap 是目前 Go 生产环境最常用的高性能日志库，但它的 SugaredLogger 不是开箱即用的 HTTP 中间件，需要手动封装。
func Logger(zapLog *zap.Logger) func(http.Handler) http.Handler {
return func(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
start := time.Now()
ww := &responseWriter{ResponseWriter: w, statusCode: 200}
next.ServeHTTP(ww, r)
zapLog.Info("http request",
zap.String("method", r.Method),
zap.String("path", r.URL.Path),
zap.Int("status", ww.statusCode),
zap.Float64("duration_ms", float64(time.Since(start))/float64(time.Millisecond)),
zap.String("ip", realIP(r)),
)
})
}
}
-
responseWriter要包装http.ResponseWriter才能捕获真实 status code -
realIP函数需检查X-Forwarded-For和X-Real-Ip，但别盲目信任代理头 - 生产环境务必用
zap.NewProduction()，开发可用zap.NewDevelopment()
日志轮转和异步写入不是可选项，是上线前必须确认的点
不轮转的日志文件会撑爆磁盘；同步刷盘在高 QPS 下会拖慢整个 HTTP 响应。这两项标准库 log 都不支持，zap 也需额外配置。
立即学习“go语言免费学习笔记（深入）”；
- 轮转推荐用
lumberjack：传给zapcore.AddSync的io.Writer必须是它实例化的WriteSyncer - 异步写入靠
zap.NewCore+zapcore.NewTee或直接用zap.NewAsync（注意：它会丢最后几条日志，进程退出前要Sync()） - 日志路径别硬编码，通过 flag 或 env 注入，比如
--log-dir=/var/log/myapp
真正麻烦的从来不是“怎么打日志”，而是“日志是否全、是否可查、是否影响服务”。轮转策略配错、异步未 Sync、IP 解析逻辑漏掉内网代理——这些地方一出问题，排查成本远高于写日志本身。
