Go标准库log包无法满足分级和异步需求，因其无内置日志级别、无结构化字段、无上下文传递，且每条日志同步阻塞执行格式化与写入，高并发下易成性能瓶颈。
为什么直接用 log 包无法满足分级和异步需求
Go 标准库的 log 包只提供基础同步输出，不支持日志级别（如 DEBUG/WARN）、上下文字段、格式化钩子，更没有内置异步缓冲或写入队列。一旦高并发打日志，log.Printf 会阻塞调用方，尤其写文件或网络时延迟明显。这不是配置问题，是设计定位不同——它本就不是为生产级日志系统设计的。
选 zap 还是 zerolog？关键看你的结构化需求
两者都支持分级和异步，但行为差异直接影响你后续扩展：
-
zap默认使用zap.NewProduction()启动异步模式（内部用zapcore.NewCore+zapcore.NewSampler+zapcore.Lock），但需显式调用logger.Sync()才能确保日志落盘，否则进程退出可能丢日志； -
zerolog的异步靠zerolog.NewConsoleWriter().With().Timestamp().Logger()不生效，必须用zerolog.New(zerolog.NewConsoleWriter()).With().Timestamp().Logger()，且真正异步要包装成zerolog.ConsoleWriter{Out: os.Stdout, Async: true}—— 注意：这个Async是 writer 层的 goroutine 缓冲，不是 logger 层的； - 若需 JSON 结构化日志并对接 ELK，
zap的zapcore.JSONEncoder更稳定；若偏好链式 API 和零分配，zerolog的.Str("key", "val").Int("code", 200)更顺手。
如何让 zap 真正异步且不丢日志
常见错误是只调 zap.NewProduction() 就以为万事大吉，结果 SIGTERM 后部分日志消失。关键在初始化和关闭流程：
- 用
zap.New(zapcore.NewCore(...), zap.AddCaller(), zap.AddStacktrace(zapcore.ErrorLevel))显式构造，避免默认生产配置隐藏细节； - 异步核心必须用
zapcore.NewCore+zapcore.NewLock+zapcore.NewMultiWriteSyncer组合，例如写文件时：file, _ := os.OpenFile("app.log", os.O_CREATE|os.O_WRONLY|os.O_APPEND, 0666)，再套zapcore.AddSync(file)； - 必须在
main函数退出前调defer logger.Sync()，否则缓冲区里未 flush 的日志直接丢失； - 如果用
zap.L()全局实例，注意它默认不启用异步，得用zap.ReplaceGlobals(logger)替换，且仍需手动Sync()。
分级日志怎么避免误用 Info 当 Debug
分级不是加个函数名就完事。很多团队把所有日志塞进 logger.Info()，导致无法按需过滤。真正有效的分级依赖两点：
立即学习“go语言免费学习笔记（深入）”；
- 开发阶段用
logger.Debug()前加条件开关：if cfg.Debug { logger.Debug("slow query", zap.String("sql", sql)) }，避免字符串拼接和对象序列化开销； - 线上环境禁止
Debug级别输出，但保留其存在——因为某些故障需临时降级到Debug，这时靠atomic.Value动态切换日志等级比重启服务更安全； - 不要在
Warn里放预期外错误（比如数据库连接失败），那该是Error；Warn只用于“业务可容忍但需关注”的场景，例如缓存穿透率超阈值。
异步和分级本身不难配，难的是让每个开发者理解：日志不是调试副产品，而是可观测性的第一现场。漏掉 Sync()、混淆 Warn 和 Error、在热路径无条件调 Debug，这三件事比选哪个库更容易毁掉整个日志体系。
