gorm钩子按数据库操作生命周期严格执行而非定义顺序：beforecreate在insert前，afterdelete在删除后；save/update/delete等操作触发对应钩子链，beforesave与专用钩子共存且有序调用。
钩子函数在 GORM 中不是按你定义的顺序执行，而是严格绑定在数据库操作生命周期上——BeforeCreate 一定在 SQL INSERT 之前，AfterDelete 一定在 UPDATE deleted_at（或物理 DELETE）之后，中间没有插队空间。
钩子执行顺序由操作类型决定，不是代码书写顺序
GORM 不会扫描结构体里方法的定义顺序，它只看当前调用的是 Create、Save 还是 Delete。比如：
-
Save会依次触发BeforeSave→BeforeUpdate（若记录已存在）或BeforeCreate（若为新记录）→ 实际 SQL 执行 →AfterUpdate或AfterCreate→AfterSave -
Delete触发BeforeDelete→ SQL 执行（软删或硬删）→AfterDelete -
Find类查询只触发AfterFind，且仅当结果非空时才调用
注意：BeforeSave 和 AfterSave 是通用钩子，但它们不会替代 BeforeCreate 等专用钩子——GORM 会同时调用两者，顺序是 BeforeSave → BeforeCreate → ... → AfterCreate → AfterSave。
哪些场景必须用钩子，而不是在业务层手动处理
钩子真正不可替代的地方，在于它能保证逻辑与 ORM 操作原子绑定，绕不开、漏不掉。典型强需求包括：
- 自动填充审计字段：比如
CreatedAt、UpdatedAt必须在 DB 层写入，不能依赖业务层传入时间（避免客户端伪造、时区错乱） - 软删除联动：在
BeforeDelete中检查是否允许删除，或自动记录DeletedBy字段，此时事务上下文仍完整 - 数据一致性校验：如库存扣减前在
BeforeUpdate中查当前值并做 CAS 判断，防止并发超卖 - 敏感字段加密：密码、手机号等必须在
BeforeSave中加密，确保即使绕过业务层直接调用db.Create也不会明文落库
别把日志打点、消息通知这类副作用逻辑塞进钩子——它们失败不该阻断主流程，而钩子返回 error 会直接中止整个 DB 操作。
容易踩的坑：事务、错误处理与嵌套调用
钩子运行在 ORM 的事务上下文中，但有几点极易出错：
-
tx参数是当前操作所属的 *gorm.DB 实例，不是新开事务；你在钩子里调用tx.Create会和主操作共用同一事务，但调用db.Create（全局 db 实例）则会新开事务，导致数据不一致 - 钩子返回 error 会中断整个操作，但
After*钩子即使报错，SQL 已执行完毕，无法回滚——所以验证类逻辑只放Before*，清理/通知类放After*并忽略 error - 慎用
AfterFind做懒加载：它对每条记录都调用一次，如果里面再查关联表，N+1 问题立刻爆炸；改用Preload或Joins - 钩子内部再调用同模型的
Create/Update，可能触发无限递归（比如AfterCreate又创建一条日志，日志模型也有AfterCreate）——加标记字段或用Session隔离
最常被忽略的一点：AfterFind 不会在 Count、FirstOrInit、Raw 查询中触发，它只对 Find、First、Take 等返回结构体实例的方法生效。
