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，等于主动给磁盘找活干。
