用pprof定位日志性能瓶颈：CPU profile看runtime.Caller和os.write占比，goroutine profile查通道阻塞与writer状态，重点监控flush延迟、丢弃率及系统调用频次。
用 pprof 定位日志写入的 CPU 和阻塞热点
直接看 runtime.Caller 和 os.write 占比，就能判断日志是否拖慢主线程。Go 自带的 pprof 是最准的切入点，不用猜、不靠经验。
实操建议：
- 启动时加
net/http/pprof，压测中访问/debug/pprof/profile?seconds=30抓 30 秒 CPU profile - 重点关注
log.(*Logger).Output、zap.(*logger).checkWrite或slog.(*textHandler).Handle的调用栈深度和耗时占比 - 若
runtime.Caller出现在 top 3，说明开了log.Lshortfile或 zap 的CallerSkip过深，必须关或调小 - 若
syscall.Syscall或internal/poll.(*FD).Write占比高，说明 I/O 阻塞严重，要切异步或加缓冲
查 goroutine 阻塞点：日志协程是否卡死或背压堆积
异步日志不是“起了 goroutine 就万事大吉”，runtime.GoroutineProfile 或 /debug/pprof/goroutine?debug=2 能暴露真实状态。
常见错误现象：
立即学习“go语言免费学习笔记（深入）”；
- 后台日志 goroutine 停在
chan send—— 通道满且没default分支，主流程被卡住 - 大量 goroutine 停在
os.File.WriteString或bufio.Writer.Write—— 文件句柄失效、磁盘满或lumberjackrotate 同步阻塞 - goroutine 数持续增长 —— writer panic 后未 recover，协程静默退出，新日志全堆积在 channel 里
关键参数差异：自己手写的 chan *LogEntry 缺少无锁环形缓冲和批量刷盘，而 zapcore.NewAsyncCore 内置这些，背压控制更稳。
监控 WriteSyncer 的 flush 延迟与丢弃率
对 zap / slog / zerolog 等库，真正影响性能的是 WriteSyncer 实现——它决定日志何时落盘、是否丢。
实操建议：
- 不要只看吞吐量，重点抓
flush latency（从写入 channel 到完成Write的耗时）和drop count（default分支触发次数） - 用
zapcore.Lock包裹文件时，如果并发高，锁争用会抬高延迟；换成zapcore.AddSync+bufio.NewWriterSize(file, 32*1024)更稳 -
lumberjack.Logger的Rotate是同步操作，高峰期 rotate 瞬间延迟可飙到 200ms+，必须设LocalTime: true和Compress: false - 缓冲区大小别拍脑袋定：1024～8192 是安全区间；超 5w QPS 必须配磁盘队列，纯内存扛不住
对比不同日志路径的系统调用频次
每条日志背后都是若干次 write、fsync、openat，用 strace -e trace=write,fsync,openat -p $(pidof yourapp) 直接看底层行为。
容易踩的坑：
- 开了
os.O_SYNC—— 每次write都等磁盘物理写入，P99 延迟跳变，只该用于Error/Panic直写路径 - 用
fmt.Sprintf拼好字符串再传给log.Printf—— 即使日志被等级过滤，也白耗 CPU 做格式化 - 没调
w.Flush()或没定时 flush —— 缓冲区满才刷，导致日志延迟不可控；正确做法是每秒或每 1MB 主动触发 - 日志路径含相对路径或符号链接 ——
openat频次翻倍，应统一用绝对路径 + 预打开文件句柄
最常被忽略的点：异步不是万能解药，它把问题从「阻塞」转成「丢日志」或「延迟不可控」。必须有独立监控项盯住 channel 长度、flush 耗时、panic 次数，而不是依赖 defer logger.Sync() 一招鲜。
