审计日志应记录user_id、ip、method、path、event_type、status_code、error_message（摘要）、changed_fields等字段，避免敏感信息；用AuditEvent接口统一模型，WriteAuditLog需在业务明确结束点调用，异步写入并脱敏以平衡可追溯性与性能。
审计日志该记录哪些字段才够用又不冗余
核心不是“全量记录”，而是能回溯操作主体、行为、目标和结果。漏掉 user_id 或 request_id 会导致无法关联请求链路；硬塞 user_password 这类敏感字段则违反安全底线。
-
user_id（或auth_token_hash，避免明文）、ip、method、path是基础身份与入口信息 -
event_type（如"user_update"、"role_grant"）比笼统的"update"更利于后续过滤分析 -
status_code和error_message（仅记录错误码或摘要，不记堆栈）区分成功/失败场景 - 避免记录原始请求体（
body），改用changed_fields字段以 map 形式声明变更项，例如{"email": ["old@example.com", "new@example.com"]}
用结构体嵌入还是接口抽象来统一日志模型
选接口更灵活，尤其当不同业务模块对“审计事件”的定义有差异时（比如支付模块需加 order_id，权限模块需加 target_role）。结构体嵌入容易导致字段膨胀或强制填充空值。
推荐定义 AuditEvent 接口：
type AuditEvent interface {
GetEventType() string
GetUserID() string
GetTimestamp() time.Time
GetMetadata() map[string]interface{} // 业务自定义字段存这里
}
各业务模块实现自己的结构体，只暴露必要方法，不暴露内部字段——这样既避免强耦合，又方便用反射或 JSON 序列化统一处理。
立即学习“go语言免费学习笔记（深入）”；
- 不要让所有事件都嵌入同一个大结构体，否则新增字段要改全量代码
-
GetMetadata()返回map[string]interface{}而非json.RawMessage，便于中间件做通用字段注入（如自动加request_id） - 接口方法名带
Get前缀，明确是只读语义，防止误写逻辑
日志写入时机：defer 还是显式调用 WriteAuditLog
不能依赖 defer 记录最终结果——HTTP handler 中 panic 未被捕获时，defer 可能不执行；事务中 rollback 后，defer 仍会写入错误日志，造成数据不一致。
- 必须在业务逻辑明确结束点写入：HTTP handler 的
return前、数据库事务Commit()或Rollback()之后 - 封装一个
WriteAuditLog(ctx context.Context, event AuditEvent)函数，内部用ctx控制超时和取消，避免日志写入阻塞主流程 - 异步写入需谨慎：若用 goroutine 直接发消息到 Kafka，失败时无重试机制，建议走带缓冲的 channel + 单独消费者 goroutine，失败时落本地文件备用
如何避免审计日志成为性能瓶颈
最常见陷阱是把日志序列化和 I/O 放在主请求路径里同步执行。哪怕只是 JSON 编码 + 写文件，QPS 上千时也会明显拖慢响应。
- 禁止在 handler 中直接调用
os.WriteFile或log.Println；必须走异步队列 - 序列化尽量用
jsoniter替代标准encoding/json，实测快 2–3 倍，且支持jsoniter.ConfigCompatibleWithStandardLibrary无缝替换 - 字段值做轻量级脱敏：比如
phone字段写入前转成"138****1234"，而非依赖下游系统处理，减少传输和存储压力 - 本地磁盘写入用
bufio.Writer批量刷盘，单次写入不少于 4KB，避免小 IO 频繁触发系统调用
真正难的是平衡可追溯性与开销——比如是否记录完整 SQL？通常只记 query_template（"UPDATE users SET status=? WHERE id=?"）和参数类型（["active", 123]），不记参数值，既满足审计要求，又规避敏感信息泄露风险。
