recover返回值必须先判空再断言：若r := recover()为nil，类型断言无效；非nil时需先r != nil检查，再用ok模式断言或fmt.Sprintf安全转字符串，避免二次panic。
recover返回值必须先判空再断言
直接对recover()结果做类型断言（如r.(error)）极大概率导致测试或运行时二次 panic——因为recover()返回interface{}，而实际 panic 值可能是string、int、自定义 struct，甚至 runtime 内部未导出类型。
安全做法是：先检查是否为nil，再用类型判断或安全转换：
-
if r := recover(); r != nil { ... }是必要前置 - 若期望是
error，用err, ok := r.(error)，再验证ok为true - 若不确定类型，统一用
fmt.Sprintf("%v", r)转字符串日志，不崩溃、不失真 - 避免
errors.As(r, &e)——该函数要求r本身是error接口类型，否则 panic
panic传error时，recover后别直接调.Error()
即使recover()拿到的是error，也不能假设它一定实现了Error()方法（比如某些第三方库 panic 的是*url.Error，但字段可能为 nil）。
更稳妥的链式处理方式：
立即学习“go语言免费学习笔记（深入）”；
Openclaw Auto Recovery
下载
OpenClaw 基础设施心跳监控与自动恢复：部署/卸载心跳守护进程，配置主机监控（Gateway、磁盘、内存、CPU、进程），设置飞书告警，自动重启故障Gateway。适用关键词：心跳监控、heartbeat daemon、服务器告警、自动重启、健康检查、auto recovery。
- 先
err, ok := r.(error)确认类型 - 再
if ok && err != nil才调err.Error() - 若需结构化提取（如 HTTP 状态码），优先用
errors.As()配合具体 error 类型指针，但必须确保r是error且非 nil - 对自定义 panic 值（如
panic(MyError{Code: 500})），应在 recover 后用_, ok := r.(MyError)明确断言，而非泛化处理
测试recover时，类型断言失败会导致测试崩溃而非失败
单元测试中写assert.Equal(t, "expected", r.(string))非常危险：一旦r不是string，测试进程会直接 panic 退出，连失败日志都看不到。
正确测试姿势：
- 用
assert.NotNil(t, r)确认捕获成功 - 用
assert.True(t, ok)验证类型断言结果，而不是强转 - 对 string panic：
assert.Equal(t, "boom", fmt.Sprintf("%v", r))（安全兜底） - 对 error panic：
err, ok := r.(error); assert.True(t, ok); assert.Equal(t, "msg", err.Error())
跨 goroutine panic 导致 recover 返回 nil，但类型断言毫无意义
如果recover()返回nil，任何后续类型断言都无效——这不是类型问题，而是根本没捕获到 panic。常见于子 goroutine 中触发 panic，而 defer 在主 goroutine 注册。
此时应放弃类型断言，优先排查 panic 是否发生在其他 goroutine：
- 在 defer 函数里加
buf := make([]byte, 4096); runtime.Stack(buf, false); log.Printf("stack: %s", buf) - 观察堆栈是否包含目标 goroutine 名称或 panic 行号
- 确认 panic 发生位置是否在
go func() { ... }()内部 - 每个可能 panic 的 goroutine 入口处必须独立配
defer func() { if r := recover(); r != nil { ... } }()
