GORM的AfterCreate/AfterUpdate钩子无法直接记录完整操作日志，因其仅接收*gorm.DB和模型实例，缺乏HTTP上下文（如用户ID、traceID、IP）、无法获取旧值或变更字段，且同步写日志易拖慢主流程；需通过WithContext透传审计信息，并异步安全落库。
为什么 GORM 的 AfterCreate 和 AfterUpdate 钩子不能直接记录完整操作日志
因为钩子函数里拿不到调用方上下文（如用户 ID、请求 traceID）、HTTP 方法、IP 地址，甚至无法区分是 API 请求触发还是后台定时任务触发。GORM 钩子只接收 *gorm.DB 和模型实例，属于纯数据层逻辑，和业务上下文天然隔离。
- 钩子内调用
gin.Context或context.Context会引发 panic —— 它们根本不在作用域里 -
BeforeUpdate拿不到旧值（除非手动查一次），AfterUpdate又没提供变更字段对比能力 - 多个 goroutine 并发写同一张日志表时，若没加事务或唯一约束，可能产生重复日志或主键冲突
如何把 HTTP 请求上下文注入到 GORM 操作中
必须在 DAO 层调用前，把关键审计字段（如 operator_id、trace_id、client_ip）塞进 context.Context，再透传给 GORM 的 Session。GORM v2 支持通过 WithContext() 绑定上下文，且该 context 会在所有钩子中可用。
- 在 Gin 中间件里构造审计上下文：
ctx = context.WithValue(c.Request.Context(), "audit", AuditInfo{UserID: uid, TraceID: tid, IP: ip}) - DAO 调用时显式传入：
db.WithContext(ctx).Create(&user) - 在钩子里用
db.Statement.Context.Value("audit")提取，注意类型断言和 nil 判断 - 不要依赖全局变量或单例存储上下文 —— 微服务多实例下会串数据
怎样在钩子里安全地写操作日志而不拖慢主流程
直接在 AfterCreate 里同步调用 logDB.Create() 是危险的：一旦日志库抖动或慢 SQL，主业务事务会被卡住。必须异步 + 降级 + 限流。
- 用带缓冲 channel + worker goroutine 消费日志事件，缓冲区满则丢弃（日志非核心链路）
- 异步写入前检查
db.Statement.Context.Err() != nil，避免主流程已 cancel 还继续发日志 - 日志结构体里必须包含原始操作的
db.Statement.SQL和db.Statement.Args（脱敏后），否则查问题时无法还原现场 - 对高频操作（如用户登录态刷新）加采样率控制，比如
rand.Float64() 才记录
为什么 UpdatedAt 字段更新也会触发日志，以及怎么过滤掉它
GORM 默认开启 FullSaveAssociations 或使用 Save() 时，哪怕只改了 UpdatedAt，也会走 AfterUpdate 钩子 —— 这会导致大量无意义日志。必须在钩子里识别“真实业务字段变更”。
- 用
db.Statement.Destination获取被更新的模型实例，再对比db.Statement.ChangedColumns()返回的字段名列表 - 排除
"updated_at"、"version"、"lock_version"等元数据字段 - 如果变更字段为空或只剩元字段，直接 return，不生成日志
- 注意：GORM 不提供“旧值 vs 新值”差异，如需字段级变更详情，得在
BeforeUpdate里提前查一次旧记录
