Go 标准库 log 包不支持日志级别，需自行封装多个 *log.Logger 实例实现轻量分级；其硬伤包括无结构化、无法动态降级、无轮转机制及性能瓶颈，生产环境应选用 zerolog 等第三方库。
Go 标准库 log 包本身不支持日志级别，调用 log.Print 或 log.Printf 永远只是“一条日志”，没有 Debug/Info/Warn/Error 的语义区分，也无法按级别过滤或关闭。真要分级，必须自己封装、或换库——这不是配置问题，是 API 设计决定的硬限制。
用 log.New 封装多个 logger 实现轻量分级
适合脚本、CLI 工具或小型服务，不引入外部依赖。核心是为每个级别创建独立的 *log.Logger 实例，分别控制输出目标（os.Stdout vs os.Stderr）、前缀和标志。
-
log.SetFlags(0)不起作用——它只影响默认 logger；每个log.New实例需单独传 flags，比如log.LstdFlags | log.Lshortfile - 前缀要用字符串字面量，如
"[INFO] "，不能靠log.SetPrefix动态改（它只对默认 logger 有效） - 多个 logger 共享同一文件句柄时要注意并发安全：标准
log.Logger是线程安全的，但文件写入本身没问题；若重定向到同一个*os.File，也无需额外加锁 - 错误日志建议输出到
os.Stderr，避免和正常输出混在一起被管道截断
var (
InfoLog = log.New(os.Stdout, "[INFO] ", log.LstdFlags|log.Lshortfile)
WarnLog = log.New(os.Stderr, "[WARN] ", log.LstdFlags|log.Lshortfile)
ErrorLog = log.New(os.Stderr, "[ERROR] ", log.LstdFlags|log.Lshortfile)
)
InfoLog.Println("config loaded")
ErrorLog.Printf("connect timeout: %v", err)
为什么别硬扛标准 log 做生产级分级
标准库 log 的三个硬伤在真实项目里会快速暴露：
- 没有结构化能力：无法附加
user_id、req_id等字段，所有信息只能拼进字符串，后续查日志全靠正则硬啃 - 无法动态降级：你想临时打开
Debug看请求体？得改代码、重编译、重启——而zerolog.LevelVar或zap.AtomicLevel支持运行时热更新 - 无轮转机制：日志文件越写越大，磁盘爆满不是小概率事件；
lumberjack这类轮转器只能配合第三方库用，标准log没法插 - 性能瓶颈明显：每条日志都做反射、格式化、同步写入，高并发下容易成为吞吐瓶颈；
zap的零分配设计和异步选项就是为此而生
用 zerolog 快速落地分级且不踩坑
比 logrus 更轻、比 zap 更易上手，适合大多数中型服务。关键点在于初始化时就明确级别开关和字段注入方式。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 必须显式调用
zerolog.SetGlobalLevel(zerolog.InfoLevel)，否则Warn()/Error()调用会被静默丢弃（默认是Disabled） -
log.Logger = log.With().Timestamp().Logger()这句不能漏，否则时间戳不会自动加到每条日志 - 敏感字段脱敏要手动做：
.Str("auth_token", "[REDACTED]")，库本身不提供自动过滤 - 想同时输出到控制台和文件？别用
io.MultiWriter套两个zerolog.ConsoleWriter——直接创建两个独立 logger，分别配置输出目标更清晰
log.Logger = log.With().
Str("service", "api").
Timestamp().
Logger()
log.Info().Str("path", r.URL.Path).Int("status", 200).Msg("http request")
在 HTTP 中间件里做请求级分级日志的关键细节
中间件是请求日志最自然的落点，但几个地方极易出错：
-
r.Body只能读一次：想记录请求体又不想影响后续 handler？必须用io.TeeReader或httputil.DumpRequest复制，不能直接ioutil.ReadAll(r.Body) - panic 恢复后，
recover()得立刻记Error日志并带堆栈，否则异常现场就丢了；用slog.String("stack", debug.Stack())或zerolog.Stack() - trace ID 要从
X-Request-ID头读取，不存在才生成新 UUID，并通过context.WithValue透传，否则子 goroutine 里拿不到 - 健康检查接口（如
/healthz）默认不打Debug日志，高频调用下会拖慢整个服务——加个skipper函数白名单过滤掉
分级日志不是“加上去就好”，而是从第一行 logger 初始化就开始影响架构选择。最常被忽略的是：环境变量控制级别这件事，必须在 main 开头就解析并生效，而不是等某个 handler 里才判断——否则前面几十行启动日志就已经按错误级别输出了。
