gin.Default()默认启用日志中间件，影响性能，高并发下QPS可降5%–12%，P99延迟增8–15ms；应替换为slog+异步写入，或用gin.New()+手动添加Recovery和极简Logger。
gin.Default()默认启用日志中间件，**会影响性能**，尤其在高并发或高频接口场景下。它不是“慢得离谱”，但每秒几千次请求时，日志格式化、I/O写入、字符串拼接、堆分配会叠加成可观的开销——实测禁用后 QPS 可提升 5%–12%，P99 延迟下降 8–15ms。
为什么默认日志会拖慢 Gin
默认 gin.Logger() 中间件做了几件事：解析请求头、计算耗时、格式化为字符串、写入 os.Stdout（或你指定的 io.Writer）。问题出在：
- 每次请求都触发
fmt.Sprintf或类似格式化，产生小量堆分配，高频下抬高 GC 频率 - 写入
os.Stdout是同步阻塞 I/O，尤其当日志量大或终端/容器 stdout 被重定向到慢存储时，goroutine 会卡住 - 日志内容包含完整路径、查询参数、响应状态等，字段越多、字符串越长，CPU 和内存压力越明显
- 即使你只打
Info级别，Logger()也照常执行全部逻辑，不支持运行时级别过滤
生产环境推荐的日志替换方案
别删日志，要换更轻、更可控的结构化日志实现。核心是：用 slog + 自定义 handler + 异步写入。
- 用
slog.NewJSONHandler(w, &slog.HandlerOptions{AddSource: true})替代gin.Logger()，避免手动拼接字符串 - 把日志输出目标设为带缓冲的
bufio.Writer，再 wrap 到文件或管道，减少系统调用次数 - 高频路由（如
/healthz、/metrics）跳过日志中间件：r.GET("/healthz", healthHandler)不走任何中间件 - 对非关键日志（如 debug 级别），用
if gin.IsDebugging() { slog.Debug(...) }包一层，编译期可裁剪
gin.Logger() 不能直接禁用？试试这三步
直接调 r.Use() 里不注册日志中间件最干净，但若已有代码依赖默认行为，又不想大改，可用以下兼容方式：
- 初始化时用
r := gin.New()而非gin.Default()，彻底避开默认中间件 - 手动加恢复中间件：
r.Use(gin.Recovery())（必须保留，否则 panic 会崩进程） - 如需保留日志，自己实现一个极简版：
func SimpleLogger() gin.HandlerFunc { return func(c *gin.Context) { start := time.Now() c.Next() slog.Info("request", "path", c.Request.URL.Path, "status", c.Writer.Status(), "latency", time.Since(start).Microseconds()) } }它不解析 header、不打印 body、不格式化多余字段，开销降低 70%+
容易被忽略的细节：日志上下文与 goroutine 安全
在异步 goroutine 里打日志（比如处理完请求后发通知），千万别直接传 *gin.Context 进去——它不是线程安全的，且生命周期只到 c.Next() 结束。正确做法是提前提取必要字段：
- 用
c.Copy()复制一份上下文（仅限读取值，不推荐用于写入） - 更稳妥的是提取关键键值：
reqID := c.GetString("X-Request-ID")，然后在 goroutine 里用slog.With("req_id", reqID).Info(...) - 避免在日志字段里传大对象（如整个
c.Request或c.Keysmap），会导致深拷贝和内存泄漏
