Iris 的 iris.Logger() 不能直接用于 MVC 控制器，因其为未初始化的全局单例（v12+ 返回 *zerolog.Logger），而控制器需通过 app.Logger() 获取已配置实例，并手动注入或封装 ctxLogger 添加 traceID、path、method 等请求上下文字段。
为什么 Iris 的 iris.Logger() 不能直接用于 MVC 控制器日志
因为 iris.Context 生命周期短、无全局实例，而 iris.Logger() 默认绑定在应用启动时的 iris.Application 实例上，控制器方法里拿不到它——直接调用 iris.Logger().Info() 会 panic 或记录到空 handler。真正可用的日志对象必须从 ctx.Application().Logger() 获取，或提前注入。
在 Controller 中安全获取并使用日志实例
推荐方式是通过构造函数传入 iris.Application 或其 Logger，避免每次请求都重复获取。Iris 的 Controller 接口不强制实现 BeginRequest，所以不要依赖它初始化日志。
- 定义控制器时，把
logger *zap.Logger（或*iris.Logger）作为字段，并在NewXXXController(app iris.Application)工厂函数中赋值 - 若坚持用内置
iris.Logger，务必调用app.Logger()而非iris.Logger()，后者返回的是全局单例，但未初始化时为 nil - 注意：Iris v12+ 默认日志是
zerolog，iris.Logger()返回的是*zerolog.Logger，不是旧版的*log.Logger
// 示例：注入 zerolog 实例
func NewUserController(app iris.Application) *UserController {
return &UserController{
logger: app.Logger(), // ✅ 正确：从 app 获取已配置的 logger
}
}
func (c *UserController) GetBy(id int) string {
c.logger.Info().Int("user_id", id).Msg("fetching user")
return "ok"
}
如何让日志自动带上请求上下文（traceID、path、method）
Iris 不自动注入 HTTP 上下文字段，需手动在中间件中将信息写入 ctx.Values()，再由控制器读取拼接。否则所有日志都是孤立事件，无法关联请求链路。
- 在全局中间件中生成 traceID（如用
uuid.NewString()），存入ctx.Values().Set("trace_id", tid) - 控制器内通过
ctx.Values().GetString("trace_id")拿到 ID，传给logger.With().Str("trace_id", ...) - 避免在每个 handler 里重复写
With()，可封装一个ctxLogger(ctx iris.Context) *zerolog.Logger工具函数 - 不要用
ctx.Request().URL.Path直接打日志——路由参数未解析，应改用ctx.GetCurrentRoute().Path()
自定义日志输出格式与级别控制的坑
Iris 内置日志默认输出到 stdout 且无文件轮转，生产环境直接用会丢日志或撑爆磁盘。同时，app.Logger().Level(zerolog.InfoLevel) 必须在 app.Run() 前调用，否则无效。
- 替换输出目标：用
app.Logger().Output(zerolog.ConsoleWriter{Out: os.Stderr})或对接os.OpenFile实现文件写入 - 级别控制要分环境：开发用
DebugLevel，生产建议InfoLevel起，避免Debug日志淹没关键错误 - 禁用 Iris 自动日志中间件（
iris.WithoutLogger），否则会和你手动打的日志重复输出请求行 - 如果用了第三方日志库（如 zap），别混用
iris.Logger()—— 它们底层不兼容，字段结构不同
真正难的不是写一行 logger.Info()，而是确保每条日志都有可追溯的请求上下文、不干扰其他组件、且在高并发下不拖慢响应。这些细节不在文档首页，但线上出问题时，第一条日志就决定你查 5 分钟还是 2 小时。
