Ent拦截器中defer+recover必须紧邻next调用且在同一作用域，才能捕获其及下游（如数据库驱动、钩子、验证）的panic；否则仅捕获拦截器自身panic。需将panic转为error返回，避免上层误判成功。
Ent拦截器里直接用defer+recover会失效
Ent的Hook和Interceptor本身运行在调用链内部，如果在拦截器函数里写defer func() { recover() }()，只能捕获该函数内panic，而无法捕获后续next(ctx, m)执行过程中下层（比如数据库驱动、自定义钩子、字段验证）抛出的panic——因为next是另一个函数调用栈，recover作用域不覆盖它。
必须把recover放在next调用的同一层defer中
正确做法是在拦截器函数体开头就设置defer，并确保它包裹对next(ctx, m)的调用。这样panic发生时，recover能捕获到next及其所有下游调用引发的panic。
示例：
func RecoverHook() ent.Hook {
return func(next ent.Mutator) ent.Mutator {
return ent.MutatorFunc(func(ctx context.Context, m ent.Mutation) (ent.Value, error) {
// 关键：defer必须紧挨着next调用，且在同一函数作用域
defer func() {
if r := recover(); r != nil {
log.Printf("ent panic recovered: %v", r)
// 可选：转为error返回，避免程序崩溃
// 注意：这里不能直接return，需配合外层错误处理逻辑
}
}()
return next.Mutate(ctx, m)
})
}
}
- 不要把
defer写在next.Mutate调用之后——那样根本没机会执行 - 不要在
next内部再套一层匿名函数并试图在那recover——作用域不对 - recover后建议记录日志，但别直接返回
nil, nil，否则上层可能误判为成功；最好统一转成fmt.Errorf("ent operation panicked: %v", r)
Hook和Interceptor中recover行为有差异
Hook（如ent.Hook）作用于Mutation阶段，recover可捕获字段校验、钩子函数里的panic；Interceptor（如ent.Interceptor）更底层，包裹整个Client.Do流程，recover还能捕获事务开启、SQL执行、扫描结果等环节的panic。
文件删除恢复功能 v0.8.0：删除前自动备份文件（存至 `delete_backup/YYYYMMDDHHMM/` 目录），支持从备份中恢复、通过清单（manifest）搜索。具备 SHA256 完整性校验、路径遍历防护及工作区根目录（workspace-root）访问限制。支持自动清理 7 天 / 30 天前的备份。 **v0.8.0：新增 `workspace_cleaner` —— 支持定时清理临时文件，并在删除前自动执行备份。** **v0.7.0：`allowed_roots` 默认值
立即学习“go语言免费学习笔记（深入）”；
- 若你用的是
ent.Interceptor（比如注册在ent.Client上），recover位置同理：必须在next(ctx, query)前设defer - 注意
Interceptor的Query类型不是Mutation，panic来源可能是Scan、Count等方法，recover依然有效 - 多个拦截器叠加时，recover只对当前拦截器内的
next生效，上游拦截器panic仍会冒泡
recover后error处理要匹配Ent的错误约定
Ent期望拦截器返回ent.Value和error。recover拿到panic后，不能忽略错误语义——否则上层Create/Update调用会得到nil错误，行为不可控。
- 务必把panic转为
error，例如：return nil, fmt.Errorf("ent panic: %v", r) - 避免在recover里调用
log.Fatal或os.Exit，这会让整个服务退出 - 如果用了第三方库（如
pgx）触发panic，recover能兜底，但根源问题（如空指针解引用）仍需修复，不能依赖recover掩盖bug
真正难处理的不是recover怎么写，而是panic发生后如何保留原始上下文——比如哪个Entity、哪个字段、哪条SQL。这些信息在recover时已丢失，需要配合debug.PrintStack()或提前在关键点打日志。
