最直接跳过所有钩子的方式是使用 SkipHooks 会话选项：db.Session(&gorm.Session{SkipHooks: true}).Create(&user)，它禁用当前会话中全部钩子（包括 BeforeCreate、AfterUpdate 等），且不影响其他 goroutine；Save() 不触发标准更新钩子，仅执行 BeforeSave/AfterSave，非跳过而是设计使然。
用 SkipHooks 会话选项跳过所有钩子
最直接的方式是通过 Session 显式禁用钩子：GORM v2 提供了 SkipHooks 配置项，设为 true 后，当前会话中所有 Create/Update/Delete 操作都不会触发任何钩子。
常见错误是直接在全局 db 上设置——这会影响后续所有操作。正确做法是每次需要跳过时新建会话：
db.Session(&gorm.Session{SkipHooks: true}).Create(&user)
db.Session(&gorm.Session{SkipHooks: true}).Model(&user).Updates(map[string]interface{}{"name": "alice"})
db.Session(&gorm.Session{SkipHooks: true}).Delete(&user)
-
SkipHooks是会话级开关，不影响其他 goroutine 或后续调用 - 它跳过 全部 钩子：包括
BeforeCreate、AfterUpdate、BeforeSave等，不区分类型 - 软删除（
Delete）也会跳过BeforeDelete和AfterUpdate，注意清理逻辑可能失效
Save() 方法天然绕过钩子，但别误用
Save() 本身不走标准钩子链——它既不触发 BeforeUpdate 也不触发 AfterUpdate，只走 BeforeSave 和 AfterSave（如果定义了）。这不是“跳过”，而是设计如此。
很多人想跳过钩子却写成 db.Save(&user)，结果发现时间字段没更新、校验没执行，还以为是钩子失效。其实只是用错了方法：
-
Save()→ 只触发BeforeSave/AfterSave（且要求签名严格匹配） -
Update()或Updates()→ 才会触发BeforeUpdate/AfterUpdate - 真正想跳过所有钩子，还是得用
SkipHooks，而不是依赖Save()的副作用
按条件跳过钩子：在钩子内部提前返回
有时你只想对某些数据跳过逻辑（比如导入脚本中的批量初始化），不需要全局关钩子。这时可以在钩子函数里加判断：
func (u *User) BeforeCreate(tx *gorm.DB) error {
if tx.Statement.Context.Value("skip_hooks") == true {
return nil
}
u.CreatedAt = time.Now()
return nil
}
调用时传入上下文即可：
ctx := context.WithValue(context.Background(), "skip_hooks", true) db.WithContext(ctx).Create(&user)
- 这种方式更灵活，适合灰度控制或特定场景绕过
- 注意：必须在钩子内显式检查，GORM 不会自动识别上下文键
- 不要在钩子里做阻塞操作（如 HTTP 请求、锁等待），事务未提交前会拖慢整个流程
软删除场景下 AfterDelete 不执行？不是跳过，是根本不会触发
启用软删除（含 DeletedAt gorm.DeletedAt）后，Delete() 实际执行的是 UPDATE，所以 GORM 触发的是 BeforeDelete → AfterUpdate，而 AfterDelete 永远不会被调用。
如果你的清理逻辑写在 AfterDelete 里，它就永远不会跑。这不是“跳过”，是语义不匹配：
- 物理删除才走
AfterDelete：需显式调用db.Unscoped().Delete(&user) - 软删除的清理逻辑应放在
BeforeDelete中（此时DeletedAt已被赋值，但记录还在事务中） - 若硬要统一入口，可把共用逻辑抽成普通函数，在
BeforeDelete和AfterDelete里分别调用
钩子跳过看似简单，但容易混淆「没触发」和「被跳过」——前者多是签名或包路径错误，后者才是主动控制。真要跳，优先用 SkipHooks；若需细粒度控制，钩子内判条件比改调用方式更可靠。
