GORM钩子不可直接用recover，因其非goroutine运行且无内置defer；需手动加defer+recover并调用tx.AddError中断操作，否则panic将崩溃进程。
为什么不能在 GORM 钩子里直接用 recover
GORM 的钩子（如 BeforeCreate、AfterSave）是同步调用的普通函数，不是在独立 goroutine 中运行。一旦你在钩子里触发 panic（比如空指针解引用、切片越界），程序会直接崩溃——recover 只对**同 goroutine 中由 defer 触发的 panic 有效**，而 GORM 不会为你包一层 defer/recover。
常见错误现象：panic: runtime error: invalid memory address or nil pointer dereference 直接终止进程，钩子没捕获，事务也没回滚。
- 钩子函数本身没有自动
defer，你得自己加 -
recover()必须紧挨着defer，且只能在同一个函数作用域内生效 - 即使 recover 成功，GORM 也不会自动跳过后续操作或回滚事务——你得手动控制流程
怎么安全地在 BeforeCreate 里用 recover
核心做法：在钩子函数开头加 defer + recover，并显式返回错误让 GORM 中断当前操作。
func (u *User) BeforeCreate(tx *gorm.DB) error {
defer func() {
if r := recover(); r != nil {
// 记录 panic 内容（建议用 zap/slog）
tx.AddError(fmt.Errorf("panic in BeforeCreate: %v", r))
}
}()
// 这里可能 panic，比如 u.Profile.Name = "foo" 而 u.Profile == nil
u.CreatedAt = time.Now()
return nil
}
- 必须用
tx.AddError(...)，否则 GORM 仍会继续执行插入 - 不要在 defer 里 return —— 钩子函数返回值由外层决定，defer 无法改变它
- panic 后 recover 到的是 interface{}，建议转成
fmt.Sprintf("%v", r)，避免类型断言失败
AfterCommit 和 AfterRollback 能用 recover 吗
不能，也不该用。
OC SSH Tunnel Node Recovery
下载
诊断并恢复通过 SSH 隧道连接的 OpenClaw 节点。用于解决配对必需错误、隧道冲突、远程端点错误以及 SSH 目标配置错误等问题。
立即学习“go语言免费学习笔记（深入）”；
这两个钩子在事务已提交/回滚后才触发，此时 DB 状态已定。如果这里 panic，recover 只能防止进程崩溃，但业务一致性已经破坏（比如发消息失败、写缓存失败）。更合理的做法是：
- 把可能出错的副作用逻辑（如 HTTP 调用、Kafka 生产）单独封装，并自带重试和日志
- 在
AfterCommit里只做轻量、不可逆的操作（如打日志、发指标） - 真要强一致，应该用事务型消息表 + 定时补偿，而不是依赖钩子 recover
替代方案：比 recover 更稳的错误处理方式
真正健壮的做法是**避免 panic**，而不是捕获它。GORM 钩子本质是业务逻辑入口，应按普通函数来写：
- 所有指针字段访问前判空：
if u.Profile != nil { u.Profile.UpdatedAt = time.Now() } - 用
errors.Is或具体错误类型判断，而非靠 panic 后 recover - 复杂校验提前在 Service 层做，钩子里只做与 DB 强相关的动作（如填充时间戳、加密字段）
- 需要兜底？用中间件或自定义
Callbacks封装统一错误拦截，而不是每个钩子都写 defer
recover 是最后防线，不是错误处理主干。钩子里多一个 if u == nil，比五层 defer/recover 更可靠。
