recover必须在defer中调用才有效，否则返回nil；它仅捕获当前goroutine的panic，不跨goroutine或函数边界，需在可能panic的代码前注册defer，且recover后不应继续原逻辑。
recover 必须在 defer 中调用才有效
Go 的 recover 不是全局异常捕获机制，它只在当前 goroutine 的 panic 正在传播、且尚未退出函数时生效。如果不在 defer 里调用，recover 永远返回 nil，起不到保护作用。
常见错误是把 recover 写在普通逻辑分支里，比如判断失败后手动调用——这完全无效。
-
defer必须在可能 panic 的代码执行前注册（通常放在函数开头） - 一个
defer语句中调用recover()即可，多次调用无意义 - 如果函数内启动了新 goroutine，主 goroutine 的
defer对其 panic 完全无感
脚本调用场景下 panic 的典型来源
通过 Go 脚本化调用外部命令（如 exec.Command）、解析 JSON/YAML、读写文件、访问 map 未初始化 key、类型断言失败等，都容易触发 panic。这些不是“错误”，而是程序崩溃点，必须拦截。
-
json.Unmarshal遇到非法结构体字段（如非导出字段 + 没 tag）会 panic，不是返回 error -
map[key]在 map 为nil时 panic，而非返回零值 -
exec.Command(...).Output()执行失败不会 panic，但若传入空命令或nilcmd，后续调用会 panic - 第三方库内部未防御的空指针解引用（如
somePtr.Field中somePtr == nil）
recover 后如何安全继续流程
单纯 recover 住 panic 只是避免崩溃，不代表问题已解决。脚本调用流程往往需要明确失败原因、清理资源、返回可控状态，而不是静默吞掉异常。
OpenClaw 基础设施心跳监控与自动恢复：部署/卸载心跳守护进程，配置主机监控（Gateway、磁盘、内存、CPU、进程），设置飞书告警，自动重启故障Gateway。适用关键词：心跳监控、heartbeat daemon、服务器告警、自动重启、健康检查、auto recovery。
立即学习“go语言免费学习笔记（深入）”；
- 恢复后应立即检查
recover()返回值：为nil表示没发生 panic；否则是 panic 传入的 interface{} - 建议统一转成
error并记录堆栈：fmt.Errorf("panic recovered: %v\n%s", r, debug.Stack()) - 不要在 recover 后继续执行原逻辑——原上下文已不可靠（比如文件句柄可能已损坏、channel 已关闭）
- 若需重试，应在 recover 外层封装新函数调用，而非在 defer 里循环
嵌套调用时 recover 不跨函数边界
如果 A 函数调用 B 函数，B 发生 panic，A 中的 defer+recover 能捕获；但如果 B 启动了 goroutine，在 goroutine 中 panic，则 A 无法捕获——这是最常被忽略的盲区。
例如用 go func() { ... }() 异步执行脚本命令，即使外层包了 defer/recover，goroutine 内 panic 仍会导致整个进程退出。
- 异步任务必须各自独立加
defer func(){ if r := recover(); r != nil { /* log */ } }() - 使用
sync.WaitGroup等待 goroutine 结束前，确保其内部已处理 panic - 标准库
http.Server就是典型：每个 handler goroutine 都自带 recover，否则一个 panic 会让整个服务挂掉
实际脚本中，最稳妥的做法是：所有可能 panic 的入口函数（尤其是 main 或 CLI 子命令函数）顶部加统一 defer + recover，并在关键异步路径里重复加固。panic 不是错误，是失控信号——能 recover 是为了争取日志和退出时机，不是为了假装它没发生。
