recover不是错误处理机制，而是panic的捕获开关，仅在defer中且同goroutine内生效；error才是go面向业务的错误处理机制，用于可预期、可恢复的场景。

recover 不是错误处理机制，它是 panic 的捕获开关；而 error 才是 Go 真正的、面向业务的错误处理机制。

recover 只能在 defer 中生效，且只对当前 goroutine 有效

很多人写 recover() 却没效果，根本原因是它没在 defer 函数里调用，或者调用了但不在 panic 发生的同一 goroutine 中。

• recover() 必须出现在 defer 函数体内部，且该 defer 必须在 panic 触发前已注册
• 如果 panic 发生在子 goroutine 里，主 goroutine 的 recover() 完全捕获不到
• recover() 返回值是 interface{}，通常要类型断言才能拿到原始 panic 值，比如 err, ok := r.(error)

error 是返回值，panic 是控制流中断，二者设计目标完全不同

你不能用 panic 替代 if err != nil，就像不能用 return 替代 goto —— 语义和代价都错位了。

GitHub Actions Retry Recovery Audit

审计 GitHub Actions 运行，检测失败后成功的重试恢复模式，量化 flaky 重运行的浪费。

下载

• error 用于可预期、可恢复、需分层处理的场景：文件不存在、网络超时、参数校验失败
• panic 用于不可恢复、本不该发生、或必须立即终止当前逻辑分支的情况：配置缺失导致服务无法启动、map 并发写、空指针解引用
• 滥用 panic 会让调用方失去错误判断权；滥用 recover 会掩盖真正的 bug，比如把数组越界当成普通错误吞掉

recover 捕获后无法“继续执行原逻辑”，只能做清理或降级

recover() 的作用不是让函数“从断点继续往下跑”，而是让程序有机会在 panic 后做资源释放、日志记录、或返回兜底响应 —— 它不改变函数已退出的事实。

• 一旦 panic 触发，当前函数立刻终止，所有后续语句（包括 defer 之后写的）都不执行
• recover() 成功后，函数直接返回，不会回到 panic 那一行继续执行
• 常见误用：在 HTTP handler 里用 recover 捕获 panic 后试图继续写 response body —— 实际上 writer 可能已关闭或处于异常状态

真正容易被忽略的是：recover 不是安全网，而是急救包。它解决不了设计缺陷，也救不了逻辑漏洞；它只负责在系统崩塌前，把门关好、灯灭掉、日志记清。

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