afterfind 无法访问 preload 关联数据，因它在单条记录读出后立即执行，此时关联字段尚未加载；且修改字段会于后续 save() 时写回数据库，易致数据错乱或安全风险。
AfterFind 无法访问 Preload 关联数据
AfterFind 在单条记录从数据库读出后**立刻执行**，此时 GORM 还没开始加载 Preload 或 Joins 的关联字段。你在里面写 u.Profile.Name 或 len(u.Orders)，基本得到的是 nil 或零值。
常见误用：批量查用户并预加载头像：db.Preload("Avatar").Find(&users)，然后在 AfterFind 里试图处理 u.Avatar.URL——实际永远为空。
- 它对每个
user单独触发一次，不是只调一次 - 真要操作关联数据，得在业务层查完再统一遍历处理
- 或者封装一个查询函数，在
Preload后手动补逻辑
AfterFind 不适合做字段解密或时区转换
直接在 AfterFind 里给 u.Phone = decrypt(u.Phone) 或 *u.CreatedAt = u.CreatedAt.In(loc) 看似可行，但会污染后续写操作：下次 Save() 可能把解密后的明文又写回数据库，造成数据错乱。
更隐蔽的问题是 time.Time 是值类型，u.CreatedAt = u.CreatedAt.In(loc) 只改副本；必须用指针解引用：*u.CreatedAt = u.CreatedAt.In(loc) 才生效。
- 字段解密应走
Scanner/Valuer接口，对业务层完全透明 - 时区转换推荐提前缓存
*time.Location（如time.LoadLocation("Asia/Shanghai")），避免每次新建 - 别在
AfterFind里调tx.Save()或其他写操作，易引发死锁
AfterFind 对非结构化查询完全不触发
AfterFind 只在 Find()、First()、Last() 这类返回结构体切片或单实例的查询中触发。它对以下操作**静默忽略**：
-
Count()—— 返回 int，不走AfterFind -
Raw().Scan()—— 手动映射，绕过模型生命周期 -
Session().First()—— 若 session 配置了DisableHooks: true，也不触发 -
Select("name").Find()—— 字段未全选时，部分字段为零值，但钩子仍会执行（只是字段不可靠）
想统一监控耗时或打日志，应该用 BeforeQuery/AfterQuery 钩子，或实现 gorm.Logger 接口。
AfterFind 修改字段后 Save() 会把修改写回库
这是最常被忽略的副作用：AfterFind 里对结构体字段的任何赋值，都会在后续 Save() 时原样落库。比如你在里面做了 u.Status = "processed"，之后调 db.Save(&u)，这个状态就会被持久化——哪怕你本意只是临时展示。
尤其当字段是敏感信息（如解密后的手机号），这个行为会导致明文意外入库。
- 若只需读时处理，定义访问器方法（如
GetPhone()），内部按需解密并缓存结果 - 若字段必须可读可写，用自定义类型实现
sql.Scanner和driver.Valuer，让加解密发生在序列化/反序列化层 - 绝对不要在
AfterFind里直接改结构体字段，除非你明确接受它会被下次Save()写回
AfterFind —— 它的触发时机太早、影响面太广、副作用太隐晦。多数所谓“需要 AfterFind”的场景，其实更适合在业务层控制流程。
