Go 怎么写高性能日志？zap vs logrus vs slog

Golang小白一枚，正在不断学习积累知识，现将学习到的知识记录一下，也是将我的所得分享给大家！而今天这篇文章《Go 怎么写高性能日志？zap vs logrus vs slog》带大家来了解一下##content_title##，希望对大家的知识积累有所帮助，从而弥补自己的不足，助力实战开发！

zap最适合高并发低延迟场景，slog适合新项目轻量需求，logrus适合中小项目但忌用于高频路径；性能排序：zap（180ms）< slog（420ms）< logrus（2050ms）。

选 zap 还是 logrus 还是 slog？看场景，别看文档吹

直接结论：高并发、低延迟、日志量大的生产服务（比如 API 网关、实时消息处理），zap 是目前最稳的选择；新项目且不想引入第三方依赖、又不追求极致性能，slog（Go 1.21+）够用；logrus 适合中小项目快速上线，但别把它塞进每秒万级请求的 handler 里——它真会拖慢你。

原因很简单：zap 默认用 Logger（强类型字段），几乎零反射、预分配缓冲、JSON 编码走字节切片拼接；logrus 的 WithFields 和 Infof 依赖 interface{} + fmt.Sprintf，每次调用都触发内存分配和格式化；slog 折中，结构化支持好、开销比 logrus 小，但还没 zap 那种“榨干 syscall”的激进优化。

• 实测（CentOS 7/8，SSD，日志写文件）：100 万次 INFO 级结构化日志，zap 耗时 ~180ms，logrus ~2050ms，slog ~420ms
• 高频路径别用 SugaredLogger —— 它为兼容 printf 风格牺牲了 3–5 倍性能，logger.Info("msg", zap.String("k", "v")) 才是正解
• slog 的 slog.With 会复制整个 Handler，如果在循环里反复调用，小心逃逸和 GC 压力

zap.NewProduction() 看似省事，但线上一跑就卡顿？

zap.NewProduction() 默认启用了 WriteSyncer 同步刷盘 + JSONEncoder + AtomicLevel，看着安全，实际在高写入场景下容易成为瓶颈——尤其是日志目标是机械盘或 NFS 时，Sync() 会阻塞主线程。

• 必须加异步封装：用 zapcore.NewCore + zapcore.NewSampler + 自定义 WriteSyncer（如带缓冲的 lumberjack.Logger）
• 别漏掉 defer logger.Sync() —— 不调它，最后一批日志可能永远不落盘，进程退出就丢数据
• 避免在 defer 里调 logger.Sync() 太多次：一个 HTTP handler 里多个 defer？合并成一次
• 示例关键片段：

  core := zapcore.NewCore(encoder, writeSyncer, level)

  ，其中 writeSyncer 应该是 zapcore.AddSync(&lumberjack.Logger{...})，不是裸 os.File

logrus 和 slog 怎么“救”才不至于拖垮服务？

如果已用 logrus 或 slog，又没法立刻切 zap，重点不是换库，而是砍开销：

• logrus：禁用 logrus.SetReportCaller(true)（每次打日志都查栈帧）；用 logrus.WithField("k", v).Info("msg") 替代 logrus.Infof("msg %s %d", s, n)；把 logrus.Debug 全部包在 if logrus.IsDebug() { ... } 里，避免字符串拼接白干活
• slog：优先用 slog.String("k", v) 等 typed 方法，别用 slog.Any("k", struct{...})（会 deep-copy）；设置 slog.HandlerOptions.ReplaceAttr 过滤掉无用字段（比如 time.Time 默认转成 map，太重）
• 共通原则：所有日志前加级别判断，例如 if logger.Enabled(zap.DebugLevel) { logger.Debug("expensive", zap.String("res", heavyFunc())) }，别让计算白跑

轮转、压缩、采样——再快的日志库也扛不住乱写

哪怕用了 zap，单个日志文件涨到 10GB、每秒写 2 万行、字段堆满 traceID/userAgent/headers，照样会让磁盘 I/O 拉垮整个服务。这不是库的问题，是策略缺失。

• 轮转必须按大小（比如 MaxSize: 200 * 1024 * 1024）+ 时间（LocalTime: true），别只靠 logrotate —— Go 进程自己得感知切割，否则旧 fd 持有导致磁盘空间无法释放
• 高频模块（如 auth middleware）必须采样：zapcore.NewSampler(core, time.Second, 100) 表示每秒最多记 100 条，其余丢弃
• 字段宁缺毋滥：zap.String("user_id", u.ID) 可以，zap.Any("full_user", u) 千万别——序列化整个 struct 开销极大，且检索毫无意义
• CentOS 上特别注意：journald 默认会双写（console + journal），关掉它：echo 'ForwardToSyslog=no' >> /etc/systemd/journald.conf，再 systemctl restart systemd-journald

真正卡住你的，往往不是日志库本身，而是没想清楚“这条日志到底要解决什么问题”。DEBUG 日志写太多，等于在生产环境开着 profiler；INFO 日志带完整 request body，等于主动给磁盘找活干。

以上就是《Go 怎么写高性能日志？zap vs logrus vs slog》的详细内容，更多关于的资料请关注golang学习网公众号！