Go标准库log包在高并发下卡住，因其默认使用带锁io.Writer导致日志调用串行阻塞；应改用无锁、结构化、零分配的zap日志库，并正确配置TimeKey、EncodeTime、LevelEnablerFunc及WriteSyncer。
为什么直接用 log 包在高并发下会卡住
Go 标准库的 log 包默认使用带锁的 io.Writer，所有日志调用串行排队。当每秒写入上千条日志（比如 HTTP 请求打点、微服务 trace 日志），log.Println 会成为明显瓶颈，CPU 没跑满，但 goroutine 大量阻塞在 mu.Lock() 上。
常见现象包括：runtime.gopark 占比飙升、pprof 显示大量时间花在 sync.(*Mutex).Lock、日志延迟高达数百毫秒。
- 避免在 hot path（如 HTTP handler 内）直接调用
log.Printf - 不要把
os.Stderr或os.Stdout直接传给多个log.New实例——它们共享底层锁 - 即使加了缓冲（如用
bufio.Writer包裹），仍无法绕过log包自身的 mutex
用 zap 替代标准 log 的关键配置项
zap 是目前 Go 生态中性能最优、生产就绪的日志库，核心优势是无锁设计 + 结构化 + 零分配（对 hot path 友好）。但开箱即用的 zap.NewProduction() 并不适合所有场景。
必须显式控制的几个参数：
立即学习“go语言免费学习笔记（深入）”；
-
EncoderConfig.TimeKey：设为""可完全禁用时间字段（若日志系统本身已带时间戳，避免重复） -
EncoderConfig.EncodeTime：用zapcore.ISO8601TimeEncoder而非默认的zapcore.EpochTimeEncoder，减少格式化开销 -
LevelEnablerFunc：用函数替代zap.LevelEnabler接口实现，避免接口动态调用成本 - 输出目标必须用
zapcore.AddSync(&fileWriter)，不能直接传*os.File——否则丢失写缓冲和错误重试
示例片段：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
cfg := zap.NewProductionConfig() cfg.EncoderConfig.TimeKey = "" cfg.EncoderConfig.EncodeTime = zapcore.ISO8601TimeEncoder cfg.Level = zapcore.InfoLevel logger, _ := cfg.Build() // 不要忽略 error
如何安全地把日志写入 channel 而不丢数据
用 channel 做日志异步化最简单，但极易因缓冲区满或接收端卡住导致 panic 或静默丢日志。关键不是“能不能用 channel”，而是“怎么防丢”。
- channel 缓冲区大小必须明确设置（如
make(chan *LogEntry, 10000)），0容量等于同步阻塞 - 发送端务必用
select+default降级：缓冲满时走快速路径（如写入本地 ring buffer 或直接 drop） - 接收端（日志 writer goroutine）需捕获
panic并重启，否则一个异常日志（如含非法 UTF-8 字符）会让整个日志管道停摆 - 不要在
defer中发日志到 channel——goroutine 退出时 channel 可能已关闭，触发 panic
典型安全发送模式：
select {
case logger.ch <- entry:
default:
// 缓冲满，降级：写入内存 ring buffer 或直接丢弃
atomic.AddUint64(&logger.dropped, 1)
}
lumberjack 轮转与并发写冲突的真实表现
很多项目用 lumberjack.Logger 做文件轮转，但它本身**不是并发安全的**。当多个 goroutine 同时调用 Write，且恰好触发轮转（如达到 MaxSize），会出现文件句柄泄漏、新日志写入旧文件、甚至 rename 失败报 invalid argument。
根本原因：lumberjack 的 Write 方法内部未加锁，轮转逻辑（close + open + rename）不是原子操作。
- 解决方案只有两个：要么用
zap自带的WriteSyncer+lumberjack组合，并确保外部写入是单 goroutine（即只让一个 writer goroutine 调用Write） - 要么改用
fsnotify+ 手动轮转，由独立 goroutine 监听文件大小并触发切换，所有写入始终走同一个os.File句柄 - 绝对不要在 HTTP handler 里直接 new 一个
lumberjack.Logger然后log.SetOutput——每个请求都新建实例会瞬间耗尽文件描述符
轮转不是加个配置就完事，它和并发模型强耦合，最容易在压测后期才暴露问题。
