Gin 默认日志拖慢接口是因为 gin.Logger() 同步写入、无缓冲、无分级，高并发下 os.Stdout 锁争抢和系统调用抬高 P95 延迟，且健康检查等低价值日志也全量输出。
为什么 Gin 默认日志在高并发下会拖慢接口
因为 gin.Logger() 是同步写入、无缓冲、无分级的日志中间件，每条请求日志都会触发一次 fmt.Fprintf(os.Stdout, ...)，在 QPS 过千时，os.Stdout 的锁争抢和系统调用开销会明显抬高 P95 延迟。更关键的是，它默认不区分级别，连健康检查 /healthz 也照打不误。
用 Zap + 异步 writer 替换 gin.Logger()
Zap 是 Go 生态中性能最强的结构化日志库，配合 zapcore.NewCore() 和 zapcore.NewMultiWriteSyncer() 可实现真正异步落盘。重点不是“用 Zap”，而是避免阻塞 handler goroutine：
- 禁用
gin.Default()，改用gin.New()手动挂载中间件 - 把日志中间件注册到业务路由组，而不是全局：
v1 := r.Group("/v1").Use(ZapLoggerMiddleware(zapLogger)) - Zap 的
core必须使用zapcore.AddSync(zapcore.Lock(os.Stdout))或更优的lumberjack.Logger文件轮转器，不能直接传os.Stdout - 高频路径（如静态资源、健康检查）跳过该中间件，用裸
r.GET("/healthz", func(c *gin.Context) { c.Status(200) })
sync.Pool 缓存日志字段避免逃逸
如果你在中间件里频繁构造 zap.String("path", c.Request.URL.Path) 这类字段，每次都会分配堆内存。Zap 提供了 zap.Stringer 和预分配字段池的能力：
- 定义复用池：
var fieldPool = sync.Pool{New: func() interface{} { return zap.Fields(nil) }} - 在中间件中取用：
fields := fieldPool.Get().([]zap.Field)，用完defer fieldPool.Put(fields[:0]) - 避免在循环或高频 handler 中调用
zap.Any()，它会触发反射；优先用zap.Int()、zap.String()等强类型方法
别让日志成为 pprof 里的 top 函数
上线前务必用 go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30 抓一次 CPU profile。如果 runtime.futex 或 syscall.Syscall 占比异常高，大概率是日志 I/O 阻塞；如果 zap.(*CheckedEntry).Write 排进前五，说明字段构造或编码耗时超标。这时候要回看是否漏掉了异步 writer 配置，或者没关 DEBUG 级别日志。
真正的异步日志不是“开了 goroutine 就叫异步”，而是写入缓冲区不阻塞主流程、落盘由独立 goroutine 批量处理、且缓冲区大小与 flush 频率可配。Zap 的 zapcore.Lock() 只是加锁保护写入，不是异步——这点最容易被忽略。
