Golang函数panic怎么捕获？recover机制防崩溃指南-Golang-PHP中文网

recover必须在defer函数中调用且仅对当前goroutine生效；漏掉任一goroutine的recover会导致panic静默终止协程并泄漏资源，如未关闭文件、连接或锁。

golang函数panic怎么捕获？recover机制防崩溃指南

recover 不能在普通函数里调用，必须放在 defer 函数中，且只对当前 goroutine 生效；漏掉任一 goroutine 的 recover，panic 就会静默终止协程并可能泄漏资源。

recover 必须写在 defer 里，且只能捕获本 goroutine 的 panic

很多人在 main 函数开头加 defer func() { recover() }()，以为能兜住所有 panic —— 实际上它只对 main 自身 goroutine 有效。HTTP handler、定时任务、go func() { ... }() 启动的子协程，都得各自配 defer + recover。

常见错误现象：

服务日志里完全没报错，但连接数缓慢上涨、CPU 占用升高 → 很可能是某个 goroutine panic 后退出，但文件/连接/锁没清理
用 hystrix.Do 调第三方接口，结果 panic 直接冒泡导致进程退出 → 应改用 hystrix.DoC，它内部做了 recover

recover 捕获到的值类型不确定，不能直接断言 error

recover() 返回 interface{}，实际类型取决于 panic() 传入的参数：可能是 string、*runtime.Error、自定义 struct，甚至 int。用 err.(error) 强制断言，遇到非 error 类型会再次 panic。

安全做法是：

用 fmt.Sprintf("%v", r) 获取可读字符串，用于日志记录
若需结构化处理，先做类型判断：if s, ok := r.(string); ok { ... } 或 if err, ok := r.(error); ok { ... }
避免在 recover 分支里继续使用已 panic 的对象（比如空指针引发的 panic，恢复后解引用仍 crash）

goroutine panic 后不处理，会导致资源泄漏而非崩溃

Go 不会回收 panic 的 goroutine，但它会释放栈内存；真正危险的是其中持有的资源：未关闭的 *os.File、未释放的 sync.Mutex、半开的 net.Conn。长期运行的服务中，反复 spawn panic 的 goroutine 会逐步耗尽句柄或连接池。

delete-recovery

文件删除恢复功能 v0.8.0：删除前自动备份文件（存至 `delete_backup/YYYYMMDDHHMM/` 目录），支持从备份中恢复、通过清单（manifest）搜索。具备 SHA256 完整性校验、路径遍历防护及工作区根目录（workspace-root）访问限制。支持自动清理 7 天 / 30 天前的备份。 **v0.8.0：新增 `workspace_cleaner` —— 支持定时清理临时文件，并在删除前自动执行备份。** **v0.7.0：`allowed_roots` 默认值

下载

正确姿势：

每个可能 panic 的 goroutine 入口处，第一行就写 defer func() { if r := recover(); r != nil { /* 清理资源 */ } }()
在 recover 分支里显式调用 file.Close()、conn.Close()、mu.Unlock()
不要用 os.Exit() 终止，应走 srv.Shutdown() 优雅下线（配合 sync.Once 防重复触发）