Iris默认不自动记录请求日志，需显式调用app.Use(iris.Logger().Handler)启用；仅设SetLevel()无效，且子域名实例须单独注册该中间件。
用 iris.Logger() 开启全局请求日志
Iris 默认不自动记录请求日志，必须显式启用。最简单的方式是调用 iris.Logger().SetLevel(iris.LogInfo) 或更高（如 LogDebug），它会让内置的访问日志中间件生效。
注意：这个日志器只控制日志级别，真正打请求日志的是 iris.Logger().Handler 所绑定的中间件——它在 app.Use(iris.Logger().Handler) 被注册后才开始工作。漏掉这一步，哪怕设了日志级别，也看不到任何请求行。
-
iris.Logger().SetLevel(iris.LogDebug)会输出路由匹配详情、中间件执行顺序等调试信息，但不增加请求日志本身 - 生产环境建议用
LogInfo，避免LogDebug输出过多干扰项 - 日志格式固定为：
2026/11/02 11:33 GET /api/users 200 12ms，不支持自定义模板
自定义日志中间件要手动提取 ctx.Path() 和 ctx.Method()
如果默认格式不满足需求（比如要加 trace_id、用户 ID、响应体长度），就得自己写中间件。Iris 没有类似 ctx.Request().RemoteAddr 那样封装好的“请求耗时”字段，所有关键数据都得从 Context 显式拿。
常见错误是直接打印 ctx.ResponseWriter().Status() ——它在写响应前始终是 0，必须用 ctx.Record() 包装响应器，或监听 ctx.ResponseWriter().BeforeFlush() 回调。
- 获取路径用
ctx.Path()，不是ctx.Request().URL.Path（后者可能含查询参数） - 获取查询参数需单独调
ctx.URLParam("page")，ctx.Params()只返回路径参数 - 想记录响应体大小，得用
ctx.ResponseWriter().Size()，但它只在响应写出后才有值 - 不要在中间件里调
ctx.Next()前就写日志，否则看不到状态码和耗时
app.UseGlobal() 不影响子域名实例的日志配置
如果你用了 app.Subdomain("api")，那 app.UseGlobal(iris.Logger().Handler) 对 api.example.com 的请求完全无效。子域名路由是独立的 iris.Application 实例，它的中间件链和主应用隔离。
这意味着：你在主 app 上挂了日志中间件，结果所有子域请求都没日志；或者你只给子域实例开了日志，主域却静悄悄——都是因为没意识到作用域边界。
- 正确做法是对每个子域实例单独调
subApp.Use(iris.Logger().Handler) - 若多个子域共用同一套日志逻辑，把中间件封装成函数，再分别传入各实例的
Use() -
UseGlobal()只影响当前实例下所有Party分组，不穿透到Subdomain创建的子实例
JSON 请求体过大时，日志中间件可能 panic
默认日志中间件不读取请求体，但如果启用了 ctx.ReadJSON(&v) 或类似操作，而请求体超大（比如上传 Base64 图片），中间件可能因内存不足或解析失败 panic。这不是日志本身的错，而是日志和业务逻辑耦合太紧的表现。
真正安全的做法是：日志中间件只记录元数据（方法、路径、状态码、耗时、IP），绝不碰 ctx.Request().Body。业务层需要请求体时，自行处理并捕获错误。
- 避免在日志中间件里调
ctx.ReadJSON、ctx.ReadForm等可能阻塞或 panic 的方法 - 若真要记录请求体，必须限制最大长度（如
ctx.ReadBody(1024)），并用recover()包裹 - 日志中间件的耗时应控制在微秒级，任何 IO 或反序列化都会拖慢整个请求链
实际部署时，最容易被忽略的是子域名日志的独立性——它不像路由分组那样自然继承中间件，必须显式注册。这点在切流量、灰度发布时尤其关键，否则某条子域链路出了问题，连日志都看不到。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
