安全审计中间件需确保认证中间件先执行并设置ctx.User，再通过类型断言和空检查获取用户；操作类型用Method+Path拼接并脱敏敏感路径；过滤静态资源等非业务路径；用OnClose记录完整请求生命周期；日志写入须异步或带panic保护。
中间件里怎么安全获取已认证用户
直接用 ctx.User.Get() 或硬取 ctx.Request().Header.Get("Authorization") 都可能拿到空值或未校验的 token。Iris 不自动填充用户上下文，必须靠你写的认证中间件先调 ctx.User.Set(&user)，后续审计中间件才能读到真实用户。
实操建议：
- 审计中间件必须放在认证中间件之后注册（
app.Use(authMiddleware, auditMiddleware)），顺序错就拿不到ctx.User - 别假设
ctx.User.Get()一定返回非 nil：用if user, ok := ctx.User.Get().(*User); ok && user != nil做类型断言和空检查 - 匿名请求（如未登录访问公开接口）应跳过记录，避免日志里塞一堆
<anonymous></anonymous>
怎么拼操作类型又不泄露敏感参数
ctx.Request().URL.String() 或 ctx.Request().RequestURI 会把 querystring（比如 ?token=xxx&id=123）全打进去，既污染日志，又可能泄露密钥或 ID。
实操建议：
- 固定用
ctx.Method() + " " + ctx.Path()拼操作类型，例如"POST /api/order"或"GET /admin/users" - 如果必须记录参数（如管理后台查日志需要知道查了哪个 ID），只提取白名单字段：
ctx.URLParam("id")或ctx.FormValue("status")，不碰整个ctx.PostValues() - 路径里带敏感标识（如
/api/user/123/token）要提前正则脱敏：re.ReplaceAllString(ctx.Path(), "/api/user/:id/token")
为什么审计日志总漏记或重复写
常见现象是静态资源（/static/js/app.js）、健康检查（/health）、404 路由全进了审计日志，或者同一个请求被记两次——根本原因是没控制中间件生效范围，也没处理好执行生命周期。
实操建议：
- 开头加路径过滤：
if strings.HasPrefix(ctx.Path(), "/static/") || ctx.Path() == "/health" || ctx.Path() == "/metrics" { ctx.Next(); return } - 用
ctx.OnClose()记结束时间、状态码、耗时，而不是只在开头打日志；否则网络超时或 panic 导致请求没完成，日志就只有 start 没有 end - 别在
ctx.Next()前写日志——它只是“继续执行”，不是“等执行完”，必须用OnClose或手动包裹 handler 才能捕获最终结果
存数据库还是写文件？性能和可靠性怎么平衡
直接在中间件里调 AuditLogModel.Create(...) 是最危险的做法：ORM 报错、DB 连接池满、事务卡住，都会让整个 HTTP 请求 hang 住或 500。
实操建议：
- 高并发 API 层一律走异步：用
app.RegisterValue(&AuditLogger{}, logger)注入一个封装了 channel 或消息队列的 logger，中间件只 send，另起 goroutine 消费写入 - 若必须同步写，至少包
try/catch（Go 里是defer func() { if r := recover(); r != nil { /* 记 error 日志但不阻断 */ } }()） - 写文件更稳，但别用
os.OpenFile每次都打开：全局复用一个*os.File，用log.New(file, "", 0)封装，避免 syscall 开销
真正容易被忽略的是：审计日志的 “完成” 不等于 HTTP 响应写出，而是 ctx.ResponseWriter 真正 flush 到 TCP 连接那一刻——OnClose 是唯一可靠钩子，其他时机都可能误判成功。
