gin.Default() 拖慢高并发接口是因为默认启用的 gin.Logger() 频繁格式化并同步写入 os.Stdout，引发 I/O 阻塞和 ANSI 颜色转义开销，显著抬升 P99 延迟。
为什么 gin.Default() 的日志会拖慢高并发接口
因为 gin.Default() 默认启用了 gin.Logger() 和 gin.Recovery() 两个中间件，其中 gin.Logger() 每次请求都执行格式化、写入 gin.DefaultWriter（默认是 os.Stdout），在容器或高 QPS 场景下，I/O 阻塞和 ANSI 颜色转义开销会明显抬高 P99 延迟。
常见错误现象包括：
- ab 或 wrk 测试时，QPS 上不去，CPU 利用率不高但延迟飙升
- 日志文件里出现大量乱码（如
\033[36m），说明颜色控制符被写进了文件 - 生产环境磁盘 IO wait 升高，
iotop显示stdout写入频繁
关闭默认日志 + 手动注册精简版 Logger
最直接有效的做法是绕过 gin.Default()，改用 gin.New()，再按需添加中间件。这样能彻底剥离你不想要的部分。
关键点：
-
gin.SetMode(gin.ReleaseMode)必须在初始化前调用，否则gin.Logger()仍可能启用调试逻辑 - 不要直接用
os.Stdout或os.Stderr作为日志输出目标——它们不是线程安全的，且无法控制格式 - 若仍需请求日志，优先使用
gin.LoggerWithWriter()替代默认gin.Logger()，并指定无色、结构化 writer
示例：
r := gin.New()
gin.SetMode(gin.ReleaseMode)
// 关闭默认日志，只在需要时加
r.Use(gin.Recovery()) // 保留 panic 捕获
// 如需记录访问日志，用自定义 writer
f, _ := os.OpenFile("access.log", os.O_CREATE|os.O_WRONLY|os.O_APPEND, 0644)
r.Use(gin.LoggerWithWriter(f)) // 不带颜色，纯文本追加
用结构化日志库替换 gin.Logger()
原生 gin.Logger() 是文本格式、不可过滤、难解析。上生产必须换掉。Logrus 或 Zap 是主流选择，但要注意集成方式——不能简单把 logger 当作中间件“套一层”。
正确做法是：
- 在 handler 内部用
c.Request.Context()携带 trace ID，注入到结构化 logger 中 - 避免在中间件里直接调用
logger.Info()，改用c.Set("logger", l.WithField(...))下发实例 - Zap 的
Logger.With()返回新实例，轻量且 goroutine 安全；Logrus 同理用WithFields() - 禁用
gin.Logger()后，所有日志由你控制时机和字段，比如只记录非 200/204 响应、或仅采样 1% 请求
性能影响：Zap 比原生 gin.Logger() 快 3–5 倍，尤其在开启异步写入（zapcore.AddSync() 包裹文件 writer）后，基本不阻塞主流程。
别忽略日志轮转与写入目标的开销
很多人以为“把日志写到文件就完了”，但没意识到 os.OpenFile 每次打开、io.WriteString 每次系统调用、没有缓冲区，都会成为瓶颈。
容易踩的坑：
- 用
os.Create()覆盖日志，导致历史丢失；应该用os.O_APPEND - 没做日志轮转，单个文件涨到几十 GB，
tail -f卡死，logrotatereload 失败 - 在容器中把日志写进本地文件，却没挂载
emptyDir或外部卷，重启即丢 - 用
io.MultiWriter(os.Stdout, file)同时输出终端和文件，但os.Stdout在非 TTY 环境下会失败或阻塞
建议方案：用 lumberjack.Logger 封装文件 writer，自动切割；或直接对接 Loki / Fluent Bit，走网络写入，把 IO 压力移出服务进程。
真正卡住性能的，往往不是“要不要记日志”，而是“怎么写、写哪、写多少”。生产环境里，一个没配缓冲区的文件 writer，比少记一条日志的影响大十倍。
