recover必须直接写在defer函数体里，不能藏在嵌套函数中；否则因栈帧不匹配导致recover返回nil、panic继续冒泡。正确做法是defer func(){if r:=recover();r!=nil{...}}()，复用逻辑应通过闭包而非函数调用。
recover 必须直接写在 defer 函数体里，不能藏在嵌套函数中
你在 defer 里定义了一个匿名函数，然后在这个匿名函数里又调用另一个函数，再在那个函数里调用 recover() —— 这种写法完全无效。Go 的运行时只认「当前 defer 函数帧」是否匹配 panic 发生时的栈帧，而嵌套调用会破坏这个匹配关系。
常见错误现象：
-
recover()总是返回nil，即使 panic 已发生 - panic 继续向上冒泡，最终导致程序崩溃
- 日志里看不到 recover 日志，但服务莫名退出
正确做法只有这一种：
defer func() {
if r := recover(); r != nil { // ✅ 直接、平级、无包装
log.Println("panic caught:", r)
}
}()
不能写成这样：
defer func() {
handleRecover() // ❌ handleRecover 里调用 recover() 无效
}()
func handleRecover() {
if r := recover(); r != nil { ... }
}
为什么嵌套函数里的 recover() 拿不到 panic？
Go 编译器在生成 recover() 调用时，会自动插入当前函数帧的栈指针（getcallerfp()），用于校验调用栈是否与 panic 发生位置“同层”。一旦你把 recover() 移到另一个函数里，这个指针就指向了新函数的帧，不再匹配 panic 帧 —— 所以 runtime 直接跳过，返回 nil。
关键点：
诊断并恢复通过 SSH 隧道连接的 OpenClaw 节点。用于解决配对必需错误、隧道冲突、远程端点错误以及 SSH 目标配置错误等问题。
-
recover()不是普通函数，它依赖编译器注入的隐式参数 - 这个隐式参数只在 defer 定义的函数作用域内有效
- 哪怕只是包一层
func() { recover() }，也已脱离原始 defer 帧
想复用 recover 逻辑？用闭包传参，别传函数
如果你多个地方都要做类似日志+返回默认值的 recover 处理，不要封装成独立函数，而是用闭包捕获行为参数：
func makeRecoverHandler(logPrefix string, fallback any) func() {
return func() {
if r := recover(); r != nil {
log.Printf("%s: panic recovered: %v", logPrefix, r)
// 可以在这里设置具名返回值，或触发其他副作用
}
}
}
// 使用
defer makeRecoverHandler("divide", 0)()
这种写法本质仍是「defer 后直接执行 recover」，只是 handler 本身是动态生成的。它规避了嵌套调用，又实现了逻辑复用。
goroutine 之间 recover 不传递，panic 也不跨 goroutine 传播
这是常被忽略的边界情况：你在主 goroutine 的 defer 里写了 recover()，但 panic 是从子 goroutine 里 panic() 出来的 —— 那么 recover() 完全没用。每个 goroutine 有自己的 panic/recover 独立生命周期。
所以：
- 子 goroutine 如果可能 panic，必须自己配
defer + recover() - 主 goroutine 的
recover()只能捕获自己调用栈上的 panic - 没有“全局 recover”机制，也不存在跨 goroutine 的 panic 透传
最易错的是 HTTP handler 或 worker loop 里启 goroutine 做事，却忘了给它加 recover —— 表面服务还在，实际 goroutine 已静默死亡。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
