log包直接写文件不适合生产Web日志收集，因其缺乏轮转、并发安全、结构化输出、动态调级等能力，易导致锁竞争、磁盘爆满、日志错乱、丢失等问题；推荐zap+lumberjack组合实现高性能结构化日志。
为什么 log 包直接写文件不适合生产 Web 日志收集
Go 标准库的 log 包默认输出到 os.Stderr，即使重定向到文件，也缺乏轮转、并发安全写入、结构化字段支持等关键能力。线上服务一旦高并发打日志，容易出现文件锁竞争、磁盘爆满、无法按天/大小切分等问题。
- 多个 goroutine 同时调用
log.Printf写同一文件句柄，可能触发write: broken pipe或日志错乱（尤其配合rotatelogs时） - 没有内置 JSON 输出，排查时需额外解析非结构化文本
- 无法动态调整日志级别（如运行中从
INFO切到DEBUG） -
log.SetOutput替换为*os.File后，进程重启不自动 reopen，日志会丢失
用 zap + lumberjack 实现带轮转的结构化日志
推荐组合：Uber 的 zap（高性能结构化日志） + lumberjack（轻量轮转 writer）。它比 rotatelogs 更可控，且与 zap 的 WriteSyncer 接口天然契合。
安装依赖：
go get go.uber.org/zap go get gopkg.in/natefinch/lumberjack.v2
核心配置要点：
立即学习“go语言免费学习笔记（深入）”；
-
lumberjack.Logger必须设置LocalTime: true，否则轮转时间按 UTC 计算，和本地运维习惯不符 -
MaxSize单位是 MB（不是字节），MaxBackups: 7表示最多保留 7 个历史日志文件 - 务必用
zapcore.AddSync包裹lumberjack实例，否则zap不会调用其Sync()方法，导致日志延迟刷盘 - HTTP 请求日志建议单独用
zap.String("path", r.URL.Path)等显式记录字段，而非依赖中间件自动提取
简易初始化示例：
import (
"go.uber.org/zap"
"go.uber.org/zap/zapcore"
"gopkg.in/natefinch/lumberjack.v2"
)
func newZapLogger() (*zap.Logger, error) {
writer := zapcore.AddSync(&lumberjack.Logger{
Filename: "logs/app.log",
MaxSize: 100, // MB
MaxBackups: 7,
MaxAge: 28, // days
LocalTime: true,
})
encoderConfig := zap.NewProductionEncoderConfig()
encoderConfig.EncodeTime = zapcore.ISO8601TimeEncoder
core := zapcore.NewCore(
zapcore.NewJSONEncoder(encoderConfig),
writer,
zapcore.InfoLevel,
)
return zap.New(core), nil
}
在 HTTP handler 中注入请求上下文日志实例
不要在每个 handler 里重复调用 logger.With(...)。用 context.Context 透传带 trace ID 的子 logger，既避免全局变量，又保证链路可追溯。
- 中间件中生成唯一
trace_id（如用uuid.NewString()），并存入context.WithValue - 用
logger.With(zap.String("trace_id", tid))创建子 logger，再塞回 context - handler 函数通过
ctx.Value(loggerKey)取出该子 logger，所有日志自动携带 trace ID - 避免在子 logger 上反复调用
With()，每次调用都会拷贝字段 map，高频请求下有 GC 压力
关键代码片段：
type loggerKey struct{}
func LoggingMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
tid := uuid.NewString()
logger := globalLogger.With(zap.String("trace_id", tid))
ctx := context.WithValue(r.Context(), loggerKey{}, logger)
next.ServeHTTP(w, r.WithContext(ctx))
})
}
func MyHandler(w http.ResponseWriter, r *http.Request) {
logger := r.Context().Value(loggerKey{}).(*zap.Logger)
logger.Info("request received", zap.String("method", r.Method), zap.String("path", r.URL.Path))
}
日志采集中容易被忽略的三个细节
日志能写出来只是第一步，真正影响可观测性的往往是这些“小地方”：
-
lumberjack的Compress: true会启用 gzip 压缩归档日志，但压缩过程阻塞写入 goroutine，QPS > 500 时可能拖慢主流程，建议关闭或改用异步压缩工具（如 logrotate） - 使用
zap.Stringer记录自定义类型时，若String()方法 panic，整个日志会静默丢弃——务必加 recover 包裹 - 容器环境（Docker/K8s）中，日志文件路径必须映射到宿主机或挂载 volume，否则容器重启后日志丢失；更推荐直接 stdout 输出，由日志采集 agent（如 filebeat）统一收集
