GORM钩子无法自动获取HTTP context，必须显式调用db.WithContext(ctx)透传；需用未导出struct作context key避免冲突；AfterFind无*gorm.DB参数且不触发Preload，权限校验应前置到service层。
钩子函数里根本拿不到原始 HTTP context，必须显式透传
GORM 钩子签名是 func (u *User) BeforeCreate(tx *gorm.DB) error，里面没有 context.Context 参数。你以为中间件里塞了值就能自动出现？不会。HTTP 请求的 context.Context 默认不进钩子，除非你主动用 db.WithContext(ctx) 把它挂上去。
常见错误是：中间件里写了 ctx = context.WithValue(r.Context(), userIDKey{}, userID)，但后续调 DB 时没传这个 ctx，直接 db.Create(&u) —— 那钩子里 tx.Statement.Context.Value(userIDKey{}) 拿到的一定是 nil。
- 必须在业务入口处显式调用
db.WithContext(ctx).Create(&u)或tx := db.WithContext(ctx).Begin() -
tx.Statement.Context才是你能安全读取的上下文，它继承自你传入的那个ctx - 别在钩子里尝试从
http.Request或全局变量里“找” context，GORM 不认那些
用私有 struct 类型作 key，否则 value 会被静默覆盖
写 context.WithValue(ctx, "user_id", "123") 看似简单，实则危险。多个包都用字符串 "user_id" 当 key，谁先写谁后写、谁覆盖谁，完全不可控。GORM 钩子一读就错，还查不出原因。
正确做法是定义一个未导出的空 struct 作 key：
type userIDKey struct{}
然后统一用它：
ctx = context.WithValue(ctx, userIDKey{}, userID)
// ……
if id, ok := tx.Statement.Context.Value(userIDKey{}).(string); ok { ... }
- key 类型必须完全一致（包括包路径），
userIDKey{}和hooks.userIDKey{}是两个不同 key - value 必须是可比较类型（
string/int/struct{}），传[]byte会 panic - 别把指针或大结构体塞进去，context 设计上只适合传轻量标识信息
事务中 context 会自动穿透，但钩子内不能执行 DB 写操作
一旦你用 db.WithContext(ctx).Begin() 开启事务，这个 ctx 就会贯穿整个事务链路：后续所有 Create/Update/Find 调用，只要走的是同一个 *gorm.DB 实例（比如 tx），它们的 tx.Statement.Context 就是同一个。
这很省事，但也埋了坑：
- 在
BeforeCreate钩子里再调tx.Create(...)可能导致死锁或嵌套事务异常 - 想记录审计日志？别在钩子里直接
tx.Create(&AuditLog{})，应改用异步发消息或延迟写入 - 若真需同步落库（如关键状态变更），务必确认该操作不依赖当前事务的隔离级别，否则可能读不到刚写的数据
AfterFind 钩子拿不到 Preload 关联数据，别指望它做权限过滤
AfterFind 在 GORM 执行完 SELECT 后立刻触发，但它运行时 Preload 还没开始。也就是说，如果你写的是：
db.Preload("Profile").Find(&users)
// 此时 AfterFind 中 u.Profile 是 nil
这不是 bug，是设计顺序。想基于关联字段做逻辑（比如根据 User.Profile.Role 过滤），得换方式：
- 用
Joins+Select把需要的字段一次性查出来，再在AfterFind里处理 - 把权限检查逻辑提到 service 层，在
Find之后、返回前手动补全并校验 - 避免在
AfterFind里调tx.Preload—— 它不生效，且可能引发循环调用
最常被忽略的一点：AfterFind 是唯一一个不接收 *gorm.DB 参数的钩子（签名是 func (u *User) AfterFind() error），所以它压根没法访问 tx.Statement.Context —— 如果你需要上下文信息，必须改用 BeforeFind 或前置拦截。
