recover必须在defer函数中直接调用才有效，否则返回nil；仅捕获本goroutine的panic，子goroutine需各自设置defer+recover，并手动打印堆栈以利排查。

recover必须在defer里调用，否则永远拿不到panic值

直接写 recover() 会返回 nil，哪怕它紧挨着 panic()。Go只在“panic正在传播、且当前goroutine尚未退出”的瞬间允许捕获，而这个窗口只有在 defer 函数执行时才打开。

常见错误写法：

func bad() {
    recover() // 这里永远是 nil
    panic("boom")
}

正确姿势是把 recover() 包进 defer 注册的函数体里：

• defer 必须出现在 panic 之前（哪怕只是逻辑上，比如在函数开头注册）
• 不能写成 defer handleRecover() 再让 handleRecover 里调 recover() —— 这属于“间接调用”，失效
• 必须是 defer func() { r := recover(); if r != nil { ... } }() 这种直写形式

panic堆栈必须手动打印，log.Printf("%v", r) 不够用

recover() 返回的是 interface{}，只用 fmt.Sprint(r) 或 r.(string) 会丢掉调用栈。线上定位问题时，没堆栈等于没线索。

实操建议：

Openclaw Auto Recovery

OpenClaw 基础设施心跳监控与自动恢复：部署/卸载心跳守护进程，配置主机监控（Gateway、磁盘、内存、CPU、进程），设置飞书告警，自动重启故障Gateway。适用关键词：心跳监控、heartbeat daemon、服务器告警、自动重启、健康检查、auto recovery。

下载

• 用 debug.PrintStack() 打印完整 goroutine 堆栈（注意：它输出到 os.Stderr，确保日志收集器能捕获）
• 更推荐用结构化日志库（如 zap）记录：logger.Error("panic caught", zap.Any("panic", r), zap.String("stack", string(debug.Stack())))
• 避免只打 r 就结束——比如 panic(fmt.Errorf("db timeout")) 捕获后只剩 "db timeout"，完全看不出在哪一行触发

HTTP handler里的recover常失效，因为panic发生在子goroutine

Web服务中，http.HandlerFunc 的 defer+recover 只能捕获主goroutine的panic。但真实业务里，panic往往藏在异步逻辑里：

• 显式起的 go doAsync()，里面panic → 主handler的defer捕获不到
• 第三方SDK回调（如消息队列消费、定时任务）→ 独立goroutine，需各自加 defer recover
• Gin/Echo自带的 Recovery() 中间件也只覆盖请求主goroutine

解决方案是分层加防：

• 所有 go 启动前，统一走封装函数，例如 safeGo(func() { ... })
• 每个后台worker、定时任务入口，自己加 defer func() { recover() ... }()
• main函数开头也加一层 defer，兜住初始化阶段的panic

recover后无法继续执行原逻辑，副作用不会自动回滚

很多人误以为 recover() 是 try-catch，能“吞掉异常然后重试”。实际上，一旦 recover() 成功，函数立即 return，panic 后面的代码（包括资源释放、状态更新）全被跳过。

这意味着：

• panic 前已写入文件、已发HTTP请求、已修改全局变量 → 这些副作用不会撤销
• 想实现“降级”或“补偿”，必须靠显式控制流，比如提前检查、预分配、用error分支处理
• 别依赖 defer 里改某个变量来“传递恢复状态”，闭包捕获的是引用，不是快照

最易被忽略的一点：recover不是调试手段，而是兜底机制。真正要定位问题，得靠堆栈+traceID+上下文日志，而不是靠它“让程序不挂”。

golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！