Go 标准库 log 包不支持日志分级和结构化输出，因其仅提供 Print/Printf 等无语义级别方法，无法添加字段且输出为纯字符串，导致日志采集系统无法解析；并发写入时还存在非 goroutine 安全问题。
Go 默认的 log 包不支持日志分级，也不支持结构化输出；要实现分级 + 结构化，必须换库 —— zap 是当前生产环境事实标准，zerolog 是轻量高吞吐替代选项。
为什么不能直接用 log 包做日志分级
Go 标准库 log 只提供 Print/Printf/Panic 等方法，没有 Debug/Info/Warn 等语义级别，更无法添加字段（如 user_id、req_id）。它输出的是纯字符串，无法被日志采集系统（如 Loki、ELK）自动解析为结构化字段。
常见错误现象：
- 自己封装
log.Printf("[DEBUG] %s", msg)—— 字符串拼接无法保留类型信息，JSON 解析失败 - 用
log.SetFlags(log.Lshortfile)加路径后，仍无法过滤某一级别（比如只看ERROR） - 并发写日志时未加锁，出现日志行错乱（
log默认不是 goroutine 安全的）
用 zap 实现分级 + 结构化（推荐生产使用）
zap 分为 zap.Logger（带缓冲、高性能）和 zap.SugaredLogger（语法糖，适合快速开发）。生产环境务必用前者。
立即学习“go语言免费学习笔记（深入）”；
关键实操建议：
- 初始化时明确选择日志级别：
zap.NewDevelopment()（默认 Debug）或zap.NewProduction()（默认 Info，且禁用 caller/file 输出） - 用
With()注入静态上下文（如服务名、版本），避免每条日志重复写：logger = logger.With(zap.String("service", "api")) - 写日志时用强类型方法：
logger.Info("user login success", zap.String("user_id", uid), zap.Int("attempts", 3))—— 字段名和值类型必须显式声明，不会因类型转换出错 - 避免混用
Sugar和Logger：两者底层结构不同，Sugar的Infow()会丢失字段类型，不利于后续解析
示例（精简版）：
logger, _ := zap.NewProduction()
defer logger.Sync()
logger = logger.With(zap.String("trace_id", "abc123"))
logger.Info("request completed", zap.String("path", "/login"), zap.Int("status", 200))
用 zerolog 替代方案（适合资源受限或极致性能场景）
zerolog 零分配、无反射、默认 JSON 输出，比 zap 更快，但 API 设计更“函数式”，对新手稍不友好。
关键差异点：
- 日志级别由
zerolog.Level控制，需手动设置：zerolog.SetGlobalLevel(zerolog.InfoLevel) - 字段通过链式调用添加：
logger.Info().Str("user_id", uid).Int("code", 200).Msg("login ok") - 不支持
With()全局上下文注入，需用logger.With().Str(...).Logger()构造新实例 - 默认输出到
os.Stderr，若要写文件，必须显式传入os.File句柄（且注意Sync()调用）
常见坑：
- 忘记调用
.Msg()→ 日志不输出（静默失败） - 在循环中反复调用
logger.With()创建新 logger，但没复用 → 内存泄漏（每个 new logger 都含独立 buffer）
分级策略与线上配置要点
日志级别不是越细越好。Go 生产服务通常只用 Debug/Info/Warn/Error 四级，Panic 和 Fatal 应仅用于不可恢复错误（并触发进程退出）。
线上必须做到：
- 禁止硬编码级别：
zap.NewProduction()在 dev 环境应替换为zap.NewDevelopment()，通过环境变量控制（如LOG_LEVEL=debug） - 敏感字段绝不打日志：密码、token、身份证号等，应在业务层脱敏后再传入 logger
- 避免在 hot path（如 HTTP handler 内部循环）里打
Debug日志 —— 即使级别被关，zap的Debugw()仍会执行参数求值（造成性能浪费） - 结构化字段名统一小写 + 下划线（如
user_id、http_status），便于日志系统归一化处理
真正容易被忽略的，是日志采样和异步刷盘：高频服务若每请求都打 5 条 Info 日志，磁盘 IO 和网络带宽可能先扛不住。该上 zapcore.NewSampler 或 zerolog.NewSampler 做采样，而不是靠降低级别来“缓解”。
