必须用tx.statement.setcolumn("created_by", uid)强制注入字段才真正生效，因直接赋值结构体字段在值类型或updates操作下无效；http上下文需通过db.withcontext(ctx)透传并在钩子中从tx.statement.context取值；记录变更须在beforeupdate查库获取旧值并存入上下文，afterupdate无法获取旧值；同步写日志会拖慢主流程，应异步投递并做采样与降级。
BeforeCreate/BeforeUpdate里怎么填审计字段才真正生效
直接给结构体字段赋值（比如 u.CreatedBy = uid）在很多场景下是无效的：字段是值类型时，钩子里操作的是副本；用 Updates(map[string]interface{}) 更新时，GORM 默认只生成指定字段的 SQL，未显式设置的字段根本不会进 SET 子句。
必须用 tx.Statement.SetColumn("created_by", uid) 强制注入字段。它不依赖结构体当前值，而是直接把键值对塞进即将生成的 SQL 的 SET 部分。
-
SetColumn对单字段更新（Update("status", "done")）和批量更新（Updates(map)）都有效 - 若字段名是驼峰（
CreatedBy），GORM 默认映射为下划线（created_by），传参时用数据库列名更稳妥 - 不要在钩子里改
*u的指针字段再期待 GORM 自动识别——它只认SetColumn或完整结构体的非零值
如何把用户ID、traceID这些HTTP上下文带进GORM钩子
GORM 钩子函数签名里没有 context.Context，不能直接从参数拿到请求信息。唯一可靠路径是：调用方提前用 db.WithContext(ctx) 透传，钩子里再从 tx.Statement.Context 取值。
在 Gin 中间件里构造上下文：ctx = context.WithValue(c.Request.Context(), "audit", AuditInfo{UserID: uid, TraceID: tid, IP: ip})；DAO 层调用时必须显式传入：db.WithContext(ctx).Create(&user)。
- 钩子里取值要加类型断言和
nil判断：if audit, ok := tx.Statement.Context.Value("audit").(AuditInfo); ok { ... } - 绝不能把上下文存到 model struct 里，或用 map 塞临时字段——会污染序列化、破坏单元测试隔离性
- 全局变量或单例存储上下文在微服务多实例下必然串数据，必须走
WithContext链路
想记录“改了哪些字段”和“旧值是什么”，为什么AfterUpdate不行
AfterUpdate 看到的只有新值，旧值早已被覆盖。而 BeforeUpdate 虽然能访问原结构体，但此时数据库里的真实旧值可能已被并发修改，必须主动查库快照。
正确做法是在 BeforeUpdate 里执行一次查询：tx.Model(&Model{}).Where("id = ?", u.ID).First(&old)，再把 old 序列化后存进 tx.Statement.Context。
- 查库动作必须在
BeforeUpdate内完成，且要用tx（不是全局db），否则事务不一致 - 别在
AfterUpdate里尝试反查——此时事务已提交，旧值不可逆 - 序列化旧值建议用
json.Marshal后存字符串，避免结构体引用污染
同步写审计日志会拖慢主流程，怎么降级
审计日志写入（尤其是落库或发 MQ）是 I/O 密集型操作，同步执行会显著拉长接口响应时间，尤其在高并发或日志服务抖动时。
应异步投递并做采样与降级：
- 用 goroutine + channel 批量缓冲日志事件，避免每条都起协程
- 对低优先级操作（如
UPDATE字段少、非核心业务）做采样，比如只记录 1% 的更新 - 当日志通道满或下游超时，直接丢弃（不阻塞主流程），可配合告警监控积压量
- 避免在钩子里调用
log.Printf或fmt.Println——它们是同步且无缓冲的，同样拖慢主流程
最易被忽略的一点：审计字段注入和日志投递必须解耦。字段填充靠 SetColumn 是轻量且必须同步的；日志记录是重操作，必须异步，且失败不影响主事务成功与否。
