gin默认日志不输出到文件且无trace_id，因其gin.logger()仅写入os.stdout、格式固定、无上下文透传；需用gin.loggerwithwriter()重定向至文件并自定义formatter注入trace_id，或升级zap实现结构化日志。
为什么 Gin 默认日志不输出到文件，且没有 trace_id？
Gin 的 gin.Default() 用的是 gin.Logger() 中间件，它只往 os.Stdout 写标准格式日志，不支持文件写入、结构化字段或上下文透传。你看到的每行日志形如：[GIN] 2024/05/12 - 10:23:42 | 200 | 12.345µs | 127.0.0.1 | GET /api/user，但缺失请求 ID、用户 ID、耗时毫秒数等关键排障字段。
常见错误是直接替换 gin.Default() 为 gin.New() 后忘记手动注册 gin.Recovery()，导致 panic 不被捕获；或者用 log.SetOutput() 重定向全局 log，结果影响其他依赖包（比如 database/sql）的日志输出。
- 必须显式调用
engine.Use(gin.Logger(), gin.Recovery())，不能只靠Default() - 不要动
log.SetOutput()—— Gin 日志走自己的gin.LoggerWithWriter()控制流 - 若需 trace_id，得在中间件中生成并存入
c.Request.Context()，再从 context 取值格式化日志
如何用 gin.LoggerWithWriter() 输出到文件并加字段？
gin.LoggerWithWriter() 是 Gin 提供的可定制日志入口，它接受一个 io.Writer 和可选的 gin.LogFormatter。它不改变日志逻辑，只接管输出目标和字符串拼接方式。
典型误用：把 os.OpenFile() 返回的 *os.File 直接传进去，却没设 os.O_APPEND 标志，导致每次启动覆盖日志；或用 logrus.WithField() 混入 Gin 日志，结果字段被忽略 —— 因为 gin.LoggerWithWriter() 不解析结构体，只认字符串模板。
- 文件打开要带
os.O_CREATE | os.O_WRONLY | os.O_APPEND - 自定义格式用
gin.LogFormatter函数，参数是gin.LogFormatterParams结构体，含StartTime、StatusCode、ClientIP等字段 - 想加 trace_id，先在前置中间件里生成（比如用
uuid.New().String()），存进c.Set("trace_id", tid)，再在 formatter 里用c.GetString("trace_id")取
file, _ := os.OpenFile("access.log", os.O_CREATE|os.O_WRONLY|os.O_APPEND, 0666)
engine.Use(gin.LoggerWithWriter(file, "${time} [${status}] ${clientIP} ${method} ${path} ${latency} ${trace_id}\n"))
用 zap 替换 Gin 日志时，为什么中间件顺序不能错？
第三方日志库（如 zap）本身不兼容 gin.Logger() 接口，必须自己写中间件。关键点在于：Gin 中间件执行顺序严格从左到右，而日志中间件需要在 Recovery() 之后才能拿到最终状态码（否则 panic 时 status 还是 0）。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
另一个坑是：用 c.Next() 前没取 c.Request.Context() 里的值，或在 c.Next() 后才生成 trace_id，导致日志里 trace_id 为空或错乱。
- 中间件注册顺序应为：
recovery → 自定义日志 → 其他业务中间件，否则 recovery 拦截 panic 后，日志中间件收不到 status - trace_id 必须在第一个中间件生成，并用
c.Set()或c.Request = c.Request.WithContext()注入 context - zap 日志建议用
zap.String("path", c.Request.URL.Path)而非c.FullPath()，后者在路由未匹配时为空字符串
性能敏感场景下，日志格式化要避开哪些操作？
线上高 QPS 服务中，日志格式化开销不可忽视。最常踩的坑是：在 formatter 函数里做 JSON 序列化、调用 time.Now() 多次、或对 c.Param("id") 这类可能 panic 的方法不做判空就直接拼接。
例如用 fmt.Sprintf("%+v", params) 打印整个 LogFormatterParams，会触发反射，比纯字符串拼接慢 5–10 倍；又比如每次请求都 new 一个 bytes.Buffer，GC 压力陡增。
- 避免在日志中间件里做任何网络调用、数据库查询、或复杂正则匹配
- 时间戳统一用
params.TimeStamp.Format("2006-01-02 15:04:05")，别重复调time.Now() - 路径、参数、Header 等字段取值前先判空，
c.GetHeader("X-Real-IP")比c.Request.Header.Get()更安全 - 如果真要结构化日志，优先用
zap的logger.Info("request", zap.String("path", path))，而不是拼接字符串再喂给io.Writer
真正难的不是写格式，而是让日志既包含足够排障信息，又不在流量高峰拖垮服务 —— 这需要你清楚知道每个字段的来源成本，以及它在什么条件下可能为空或 panic。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
