iris 框架不内置操作日志审计功能，但可通过组合 iris.logger、自定义中间件、context 值透传及结构化日志库（如 logrus）实现；需提取 user_id、action 等上下文，统一在响应后记录，避免与错误日志混用，并确保审计字段完整、独立、可追溯。
Iris 框架本身不内置「操作日志审计」功能，但可通过组合 iris.Logger、中间件和自定义 Context 处理逻辑来实现——关键不在框架是否“自带”，而在于你如何拦截请求、提取上下文、结构化记录并落盘。
用 iris.Logger 记录基础访问日志
它默认输出格式化请求信息（方法、路径、状态码、耗时），适合快速启用基础审计入口：
- 仅覆盖 HTTP 层面，不含业务参数、用户身份、操作结果语义
- 日志内容不可定制字段（如缺
user_id、action_type） - 输出目标固定为
os.Stdout，需配合 Hook 或重定向才能写入文件或远程服务
启用方式简单：app.Use(iris.Logger)。但注意：它和 Recovery 中间件顺序有关，应放在 Recovery 之后，否则 panic 时日志可能丢失。
手写中间件注入操作上下文
审计的核心是把「谁在什么时间做了什么」绑定到每次请求。你需要在中间件中提取并透传关键字段：
- 从
ctx.Request().Header.Get("X-User-ID")或 JWT token 解析出user_id - 用
ctx.Values().Set("op_action", "update_user")在路由前标记操作类型 - 在 handler 执行后，用
defer或ctx.OnConnectionClose补充操作结果（成功/失败/错误码） - 避免在中间件里直接写日志——先存
ctx.Values()，统一在响应后钩子中格式化输出
示例片段：ctx.Values().Set("audit_log", map[string]interface{}{"user_id": uid, "path": ctx.Request().URL.Path})，后续由统一日志中间件消费。
对接结构化日志库（如 logrus）写审计事件
Iris 的 Context 不直接兼容 logrus.Entry，需手动桥接：
- 不要用
logrus.WithContext(ctx.Request().Context())—— 它绑定的是 HTTP 请求上下文，不是 Iris 的Context - 推荐在审计中间件末尾构造
logrus.WithFields()，显式传入ctx.Values().Get("user_id")等字段 - 使用
logrus.JSONFormatter{}确保字段可被 ELK 或 SLS 解析（尤其对接阿里云 SLS 时） - 注意并发安全：logrus 实例全局复用即可，无需每个请求 new 一个
典型字段建议包含："timestamp"、"user_id"、"ip"、"method"、"path"、"status"、"duration_ms"、"action"、"error"（如有）。
避免把审计日志和错误日志混在一起
这是最容易踩的坑：用同一个 logrus 实例同时记 debug/info 和 audit，会导致审计事件被日志级别过滤掉（比如设了 WarnLevel 就看不到 info 级操作）。
- 审计日志必须独立 logger 实例，且级别设为
InfoLevel或更低 - 不要依赖
ctx.StatusCode()判断操作成败——HTTP 200 可能对应业务失败（如返回{"code":4001,"msg":"余额不足"}） - 真正可靠的审计标记点，是 handler 执行完毕后、写响应体之前，检查业务返回值或 error
复杂点在于：有些操作跨多个 handler（如上传+处理+回调），审计事件需要关联同一 request_id。Iris 提供 <code>iris.Tracer 中间件生成 trace ID，记得提前注入并透传。
