标准log包高并发下因全局锁成为瓶颈，导致延迟上升、CPU占用高、GC压力大；应改用zap/zerolog等高性能库或自研无锁日志器，并配合采样与降级策略。
为什么标准 log 包在高并发下会成为瓶颈
Go 标准库的 log 包默认使用 os.Stderr 作为输出，并在每次写入前加全局互斥锁（log.LstdFlags 下的 mu.Lock()）。这意味着所有 goroutine 会争抢同一把锁，QPS 超过 10k 后写日志延迟明显上升，甚至拖慢主业务逻辑。
常见错误现象包括：压测时 p99 日志延迟突增至几十毫秒、CPU 火焰图中 runtime.futex 占比异常高、GC 周期变长（因大量短生命周期的 fmt.Sprintf 字符串逃逸）。
- 避免直接封装
log.Printf做“高性能”扩展——锁没去掉，只是套了层壳 - 不要在日志函数里做格式化（如
fmt.Sprintf），应延迟到真正写入前，或用预分配 buffer - 注意
log.SetOutput替换为io.Writer时，该 writer 自身是否线程安全（比如os.File是的，但自定义 buffer 不一定）
用 zap 或 zerolog 替代手写，不是偷懒而是避坑
zap 和 zerolog 都是经过生产验证的高性能日志库，核心设计差异直接影响你选型：
-
zap使用结构化日志 + 零堆分配（zap.String,zap.Int等不产生 GC），但 API 略重，需显式调用.Info()或.Sugar().Infof() -
zerolog更轻量，zerolog.New(os.Stdout).With().Timestamp().Logger()构建即用，支持链式写法，但默认开启采样和字段排序，可能带来微小开销 - 两者都不依赖反射，避免
fmt的动态类型解析；都支持异步写入（zap.Core可 wrap 成 async，zerolog.ConsoleWriter内置 goroutine channel）
示例：启用 zerolog 异步模式只需一行：
log := zerolog.New(zerolog.NewConsoleWriter()).With().Timestamp().Logger()
log = log.Level(zerolog.InfoLevel) // 控制级别
// 实际写入走内部 channel，不阻塞调用方
log.Info().Str("path", "/api/user").Int("status", 200).Msg("request completed")
自己实现简易高性能 logger 的关键三步
如果你必须自研（比如嵌入式环境、合规要求、或学习目的），绕不开这三个点：
- 用无锁 ring buffer（如
github.com/Workiva/go-datastructures/queue）暂存日志条目，避免 channel 的内存分配和调度开销 - 日志条目结构体预分配内存：
type LogEntry struct { Level uint8; Time int64; Msg [256]byte; Fields [8]Field }，避免 runtime 分配 - 单独 goroutine 消费 buffer 并批量刷盘：每次从 ring buffer 批量取（如 64 条），拼成一个
[]byte后调用file.Write()，减少系统调用次数
注意：不要用 sync.Pool 缓存日志 entry——goroutine 复用不可控，容易导致字段残留；也不要用 bytes.Buffer 做临时格式化，它内部用 slice append，仍会触发扩容和复制。
日志采样和降级策略比“快”更重要
再快的 logger，遇到每秒百万条 debug 日志也扛不住。真实场景中，性能瓶颈往往来自“不该打的日志被打出来了”。
- 按 level 采样：对
Debug级别启用1/100随机采样（rand.Intn(100) == 0），但确保 trace_id 相同的请求全量保留 - 写入失败自动降级：当磁盘满或
write返回ENOSPC时，切到内存 buffer + LRU 驱逐，而不是 panic 或阻塞 - 禁止在循环内打日志：哪怕用了 zap，
for i := range items { logger.Info("item", zap.Int("i", i)) }仍可能压垮 IO —— 改为聚合后单条输出
最容易被忽略的是日志上下文污染：一个 http handler 中多次调用 logger.With().Str("req_id", id) 会不断追加字段，最终生成超长 JSON。应该复用 root logger，或用 ctx.Value + middleware 统一注入。
