Buffalo 的 middleware.Logger 不支持真正结构化日志，字段硬编码且不可配置，需自定义中间件注入 trace_id、request_id、IP 等业务字段，并统一 logger 实例与字段规范以实现全链路结构化。
Buffalo 的 middleware.Logger 默认不结构化
它用 logrus.WithFields() 打日志，但字段名和格式是硬编码的（比如固定输出 method、path、status），且无法通过配置增减字段或改模板。你看到的 JSON 或文本只是 logrus 输出器的序列化结果，不是真正可扩展的结构化日志。
常见错误是以为加个 --log-format json 就算结构化了——其实只是把固定字段塞进 JSON 字符串，没加 trace_id、user_id、request_id 这类业务关键字段，也做不到按 level 过滤或字段索引。
-
middleware.Logger源码里字段写死在log.WithFields(map[string]interface{}{...})中，没暴露接口 - 它不读取
c.Data()或 context.Value，所以 handler 里塞进去的业务数据不会自动带上 - 生产环境默认不启用，得手动
app.Use(middleware.Logger)，但即使启用了，字段还是那几个
想加 request_id 或客户端 IP，必须重写中间件
核心逻辑是包装 http.ResponseWriter 并监听 WriteHeader 调用，同时从 buffalo.Context 提取请求信息。不能直接 patch 原始 middleware.Logger，得自己实现一个。
关键点：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 从
c.Request().Context()或c.Request().Header.Get("X-Request-ID")拿 ID；没的话用uuid.NewString()生成 - IP 要用
c.Request().RemoteAddr，但注意反向代理下需解析X-Forwarded-For—— Buffalo 不自动做这件事 - 别在中间件里调
c.Error()或c.Render()，否则会干扰原响应流程 - 复制
middleware.Logger源码（约 50 行），只改log.WithFields()里的 map，其他逻辑保留
日志输出目标要换，否则写不到文件或 ELK
middleware.Logger 底层用的是 logrus.StandardLogger()，它的 .Out 默认是 os.Stdout。想写文件、发到 Loki 或对接 Logstash，必须替换这个 .Out。
实操步骤：
- 新建一个
logrus.Logger实例，设置.Out = os.File或io.MultiWriter(...) - 把自定义中间件里的
log变量指向这个新实例，而不是用logrus.WithFields()默认的全局 logger - 如果用
logrus.TextFormatter，记得设DisableColors: true，避免日志收集器解析失败 - 线上禁用
logrus.DebugLevel，防止日志爆炸；用logrus.InfoLevel足够记录请求生命周期
panic 日志必须单独捕获，middleware.Logger 不管这个
它只记录正常请求的进出，对 panic 完全无感。而线上最需要结构化的恰恰是 panic：堆栈、请求路径、参数、IP、时间戳缺一不可。
正确做法是在 recovery 中间件里手动打结构化日志：
- 用
debug.Stack()拿完整堆栈，不要只打r的字符串表示 - 字段至少包含：
event="panic"、path=c.Request().URL.Path、method=c.Request().Method、ip=c.Request().RemoteAddr、stack=string(debug.Stack()) - 别用
c.Log().Error()，它不输出 stack；直接调新logrus.Logger实例的.WithFields().Error() - 确保 recovery 中间件注册顺序在
middleware.Logger之后，否则 panic 发生时日志还没写完就进程退出
结构化日志真正的难点不在字段怎么加，而在于所有日志入口（请求、panic、DB 查询、第三方调用）都得用同一套 logger 实例和字段规范，否则查问题时还得切好几个 schema。
