Buffalo日志需中间件注册+环境判断+底层logger替换三步协同；生产环境默认不打请求日志，须显式调用app.Use(middleware.Logger)且顺序前置，但其源码硬编码仅dev环境生效；自定义字段需重写中间件，IP需校验X-Forwarded-For；日志输出目标须在Use前替换Logger.Out。
Buffalo 的日志记录不是“配置出来”的，而是靠中间件注册 + 环境判断 + 底层 logger 替换三步协同生效；生产环境默认不打请求日志，必须显式调用 app.Use(middleware.Logger)，且顺序不能错。
middleware.Logger 在 production 为何不生效
它被硬编码在 middleware.Logger 源码里：只有 app.Options.Env == "development" 才真正执行日志逻辑。即使你写了 app.Use(middleware.Logger)，在 production 下也会直接 return，不记录任何东西。
- 不要依赖文档里“调用即生效”的说法——得看源码逻辑
- 检查方式：在
app.go中加一行log.Printf("env: %s", app.Options.Env)，确认值确实是"production" - 正确写法必须带环境判断：
if app.Options.Env == "production" { app.Use(middleware.Logger) } - 注册位置要早于所有可能提前返回的中间件（如
auth.Required、cors.Default()），否则未认证请求根本进不到 Logger
自定义日志字段（如 IP、Request-ID）必须重写中间件
middleware.Logger 不提供格式配置接口，它的日志字段是硬编码的（method、path、status、latency、size）。想加 X-Request-ID 或客户端真实 IP（而非 127.0.0.1），只能自己实现。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 核心动作：包装
http.ResponseWriter，监听WriteHeader和Write，同时从c.Request()提取信息 - IP 获取要小心：
c.Request().RemoteAddr是反向代理后的真实地址，但若前端有 Nginx，需读X-Forwarded-For头并做白名单校验 - 别在中间件里调
c.Error()或c.Render()，否则会干扰原响应流程，导致双写 header panic - 如果用了
gzip.Middleware，自定义 Logger 必须放在它之后，否则ResponseWriter被 gzip 包装过，拿不到原始字节数
日志输出目标（stdout / file / ELK）怎么改
middleware.Logger 底层用的是 logrus.Logger，默认输出到 os.Stdout。想写文件或对接日志系统，得替换它的 Out 字段。
立即学习“go语言免费学习笔记（深入）”；
- 替换时机：必须在
app.Use()之前完成，否则中间件已绑定默认 logger - 写文件示例：
middleware.Logger.Logger.Out = os.File（先os.OpenFile创建句柄） - 对接 ELK：用
logrus.TextFormatter或logrus.JSONFormatter，再配logrus.SetOutput()到网络 writer - 注意：Buffalo 启动时会自动初始化一次
logrus.StandardLogger()，如果你全局改了logrus.StandardLogger().Out，会影响框架内部日志（如 pop 迁移日志）
最容易被忽略的一点：静态资源请求（/assets/xxx.js）默认不会被 middleware.Logger 记录，除非你把它注册在 app.Use() 链最前面，且没被 app.AutomaticResourceRouting() 拦截掉——很多线上问题就卡在这条路由匹配优先级上。
