每个测试用例必须在函数内部首行使用 defer 捕获 panic，recover() 须配合类型断言安全处理，且 recover 后立即 return，不可继续执行断言或资源操作。
recover 必须写在每个测试用例的 defer 里
API 自动化测试执行器通常批量跑多个 testFunc，比如用 for range 遍历测试用例切片。如果只在主循环外加一层 defer func() { recover() }()，它根本捕获不到子函数里的 panic —— 因为 panic 发生在另一个函数栈帧里，而 recover 只对当前 goroutine 当前函数生效。
常见错误现象：某个测试用例 panic（比如 JSON 解析失败、空指针解引用），整个执行器直接退出，后续用例全跳过。
- 正确做法是：每个测试用例函数内部第一行就注册
defer func() { if r := recover(); r != nil { log.Printf("test %s panicked: %v", name, r) } }() - 别把
recover()单独写成defer recover()—— 这会在注册时立刻执行，返回nil，等于没写 - 如果测试用例本身是闭包或匿名函数调用，确保
defer在该闭包体内，而不是外层循环体
recover 后不能继续断言或写入结果集
panic 往往意味着状态已损坏：HTTP 响应体未读完、临时文件句柄丢失、全局 map 被并发写入后处于不一致状态。此时 recover() 成功只代表“没崩溃”，不代表“还能安全干活”。
- recover 后立即
return，不要接着调用assert.Equal()或往results切片 append - 避免在 recover 分支里调用
close(ch)、mutex.Unlock()等资源操作 —— 这些该放在独立的 defer 链里，与 recover 逻辑分离 - 如果必须记录失败，用带时间戳和 panic 值的独立日志，别依赖被中断的测试上下文字段
goroutine 中的 panic 必须各自防护
自动化测试执行器常启 goroutine 并发跑用例（如 go runTestCase(...)）。主线程的 defer+recover 对子协程完全无效 —— 每个 goroutine 的 panic 是隔离的。
诊断并恢复通过 SSH 隧道连接的 OpenClaw 节点。用于解决配对必需错误、隧道冲突、远程端点错误以及 SSH 目标配置错误等问题。
立即学习“go语言免费学习笔记（深入）”；
- 每个并发启动的函数开头必须自己加
defer func() { if r := recover(); r != nil { ... } }() - 别指望“统一中间件”：HTTP handler 里能靠中间件包一层，但测试执行器里没有统一入口；每个
go语句都是独立起点 - 如果用
sync.WaitGroup等待，recover 失败后记得wg.Done()，否则主 goroutine 可能死锁在wg.Wait()
recover 返回值类型不确定，必须先判空再断言
测试中 panic 可能来自不同地方：panic("timeout")、panic(errors.New("404"))、甚至 panic(struct{ Code int }{500})。直接 r.(error).Error() 会二次 panic。
- 永远先检查
r != nil，再做类型判断 - 推荐模式：
switch x := r.(type) { case string: msg = x; case error: msg = x.Error(); default: msg = fmt.Sprintf("%v", x) } - 不要把
recover()结果直接塞进结构体字段（如TestResult.Err = r）—— 类型不匹配会导致后续序列化失败
最易被忽略的是：recover 不是兜底开关，它只负责不让程序挂，但不保证数据干净、不保证资源释放、不保证并发安全。测试执行器里，比 recover 更重要的是用独立 goroutine + 超时控制 + 明确的 defer 清理链来预防 panic。
