Go 日志库怎么选：九款主流日志库横向对比

Go 日志库的选择在 log/slog 进入标准库后格局大变：老一代库加速退场，高性能双雄 Zerolog/Zap 依然坚挺。本文横向对比九款主流 Go 日志库的性能、API 风格与适用场景，帮你在项目启动或技术债治理时做出清晰决策。

核心要点速览

• 默认答案已变成标准库 slog：Go 1.21+ 内置，零依赖、API 稳定、可换后端，覆盖绝大多数需求。
• 性能双雄：Zerolog（约 81ns/op，零分配）与 Zap（约 193ns/op，零分配）仍是极限性能场景的首选。
• 老库进入退场通道：Logrus 维护模式，Apex/log、Log15 基本停更——存量维护可以，新项目别选。
• 平台侧与选型解耦：统一 JSON + stdout，观测云 DataKit 采集，换库不动平台配置。

性能基准总览

基于公开基准测试（字段化日志写入）：

结论一目了然：第一梯队（Zerolog/Zap/slog）比老库快 1-2 个数量级。

逐款点评

1. slog（标准库）：新项目的默认答案

Go 1.21 起内置。前后端分离设计（业务 API 稳定、Handler 可替换）是它最大的架构优势——今天用 JSONHandler，明天换 Zap 后端，业务代码一行不动。TextHandler/JSONHandler 内置，属性强类型，支持分组与 With 绑定。唯一槽点是强类型 API 略显啰嗦。不知道选什么，就选 slog。

2. Zerolog：性能之王

零分配设计，基准最快。链式事件 API（log.Info().Str().Msg()）写起来流畅，默认 JSON，支持采样、Hook、CBOR 二进制输出、ConsoleWriter 开发模式。适合高吞吐服务与"性能强迫症"团队。

3. Zap：Uber 出品，性能与工程化兼备

与 Zerolog 同档性能，双 API 设计（强类型 Logger + 易用 SugaredLogger）兼顾性能与开发效率。预设配置开箱即用，AtomicLevel 支持运行时调级别，Config 结构体细粒度定制。大厂背书、生态成熟。

4. Logrus：功勋老将，只维护存量

API 兼容标准库 log、WithFields 字段机制影响了一代 Go 程序员，但性能垫底（比 Zap 慢百倍级）且已进入维护模式。存量系统继续用没风险，新项目请勿引入。

5. Apex/log：极简主义遗珠

设计简洁的 structured logger，早已停更。了解即可。

6. Log15：logfmt 风格先驱

主打 logfmt 输出与 Handler 链，曾影响 slog 的设计，现已停更。slog 的 TextHandler 基本继承了它的衣钵。

7. Logf：轻量 logfmt 新秀

来自 Zerodha，专注 logfmt 结构化输出，API 极简：五个级别方法 + 交替键值对 + 默认字段。定制项少是刻意的取舍——要的就是轻。喜欢 logfmt 风格又嫌 slog 啰嗦的可以一试。

8. Phuslu/log：性能新锐

与 Zerolog 同档的零分配性能，API 也走链式风格，还内置了文件轮转等 Zerolog 不具备的能力。社区规模较小是它的主要风险。

9. Logr：接口而非实现

严格说 Logr 不是日志库，而是一套日志接口抽象——库代码只依赖 logr API，具体实现由应用方注入（zapr、zerologr 等适配器）。写 Kubernetes 生态控制器/Operator 时它是事实标准。

选型决策树

要写 K8s 控制器/可被集成的库？ → Logr 接口
确认日志是性能瓶颈（每秒数万条+）？ → Zerolog 或 Zap
想要最少依赖、最稳 API？ → slog（标准库）
喜欢 logfmt 极简风？ → Logf
存量 Logrus/Apex/Log15？ → 继续维护，按日志量排期迁移 slog

观测云落地：选型与平台解耦

九款库、一个出口：JSON 结构化 + stdout/文件 + DataKit 采集。

1. 输出契约统一：各库都能输出 JSON（Logf 的 logfmt 同样可被 Pipeline 解析），字段命名遵循团队契约（time/level/msg/service）。
2. 采集统一：观测云 DataKit 采集容器 stdout 或主机文件，JSON 自动解析；source/service 区分服务。
3. 治理统一：Pipeline 映射标准 status/time 字段；日志查看器检索聚类；监控器告警；多索引控成本；APM trace_id 关联——全部与具体库无关。
4. 换库零平台成本：从 Logrus 迁到 slog、从 slog 换 Zap 后端，平台侧配置一行不用改。

常见问题（FAQ）

slog 会不会让第三方日志库都消失？

不会。性能极限场景 Zerolog/Zap 仍有优势，且它们可以作为 slog 的 Handler 后端共存。slog 的意义是统一了"业务代码怎么写日志"，而不是消灭实现层竞争。

基准测试数据该信多少？

方向可信、数值别较真：不同机器、字段数量、输出目的地都会影响结果。第一梯队（Zerolog/Zap/slog/Phuslu）内部的小幅差异对业务基本无感；与老库的百倍差距才是选型要关心的。

团队统一用哪个库最省心？

slog。标准库背书意味着十年内 API 不会过时，新人零学习成本（会 log 就会 slog 的七八成），依赖树更干净。有特殊性能诉求的服务单独用 Zerolog/Zap，通过 slog Handler 适配器保持 API 一致。

Go 项目日志级别该怎么划？

slog 的 Debug/Info/Warn/Error 四档足够；Zerolog 多出 Trace/Fatal/Panic。建议生产默认 Info，排障动态开 Debug；Fatal 只用于启动期不可恢复错误。

系列阅读

• 上一篇：Logrus 实战指南
• 下一篇：Ruby 日志实战
• 相关阅读：Go Slog 实战 ｜ Zerolog 实战 ｜ Zap 实战

---