Golangpanic处理技巧：单协程recover不崩溃

Go 中 panic 不会跨 goroutine 传播，这虽是设计特性而非缺陷，却极易引发静默资源泄漏——未 recover 的 panic 会悄然终结协程，导致 mutex 未释放、timer 未停止、channel 未关闭等致命残留；因此每个独立 goroutine 都必须自行配置 defer+recover 进行兜底，且 recover 后绝不可继续业务逻辑，而应专注日志记录、服务降级与精准资源清理，否则看似健壮的系统将在数小时后因僵尸协程堆积而缓慢崩溃。

panic 不会跨 goroutine 传播，这是设计，不是 bug

Go 明确规定：panic 只终止当前 goroutine，其他 goroutine 完全不受影响——哪怕你在 main 里启动了 100 个子协程，其中一个 panic 了，剩下 99 个照常跑。但问题在于：没人 recover 的 panic 会打印堆栈并退出该 goroutine，如果它是关键 worker（比如监听 channel 的消费协程），它一死，后续消息就卡住；更糟的是，它可能持有了 mutex、占着 timer、没关 file 或没 close channel，直接导致资源泄漏。

• 别指望在 main 函数里 defer recover() 拦住子 goroutine 的 panic —— 它根本收不到
• 子 goroutine 一旦 panic 且未 recover，runtime 就把它干掉，不通知、不等待、不回滚
• 真正危险的不是 panic 本身，是 panic 后状态残缺 + 资源未释放，形成“静默泄漏”

每个可能 panic 的 goroutine 都得自己加 defer+recover

最稳妥的做法，是在每个独立启动的 goroutine 内部做兜底。这不是冗余，而是隔离错误边界的必要操作。常见模式是封装一个 gosafe 工具函数，或直接内联写。

go func() {
    defer func() {
        if r := recover(); r != nil {
            log.Printf("worker panic: %v", r)
            // ⚠️ 这里必须清理！
            if timer != nil { timer.Stop() }
            if mu != nil { mu.Unlock() } // 或确保已 unlock
            if ch != nil && !closed(ch) { close(ch) }
        }
    }()
    doSomethingRisky()
}()

• recover() 必须出现在 defer 声明的匿名函数中，且不能包在额外函数调用里（比如 defer handlePanic() 里再调 recover() 就失效）
• recover 后别假设变量还完好——map 可能已部分写入，struct 字段可能只改了一半
• HTTP handler、定时任务、channel 消费循环这类长生命周期 goroutine，必须加，不能省

recover 不是 error 处理，更不是重试开关

recover 成功后，goroutine 并不会回到 panic 发生点继续执行，而是从 defer 函数返回后往下走。它只提供一次“逃生出口”，用于记录、降级、清理，而不是修复后重来。

• 不要在 recover 后继续处理业务逻辑，尤其涉及数据库事务、支付、状态机流转等强一致性场景
• 频繁用 panic/recover 替代 error 返回，性能差 10–100 倍（栈展开开销大），还会掩盖本该提前校验的问题
• 第三方库内部 panic（如某些 JSON 解析器对非法 UTF-8 的处理）才需要你主动 recover；自己写的逻辑，优先用 if err != nil

容易被忽略的致命细节：recover 后的资源清理不是可选项

很多人写了 defer func(){ recover() }() 就以为万事大吉，结果 runtime.NumGoroutine() 持续上涨，几小时后 OOM。原因往往是 recover 后没关 timer、没释放 mutex、channel 没 close，导致 goroutine 卡在阻塞点上，永远活不下去也死不了。

• 检查所有可能被 panic 中断的资源生命周期：文件句柄、网络连接、sync.Pool Get/Return、context.WithCancel 生成的 cancel 函数
• 避免在 defer 里只写 recover()，后面必须跟明确的 cleanup 步骤；或者用命名返回值封装清理行为
• 测试时故意触发 panic（比如在 defer 里 panic("test")），观察是否真能 clean exit，而不是留下僵尸 goroutine

真正难的不是写 recover，是判断哪些地方该 recover、recover 后敢不敢继续跑、以及敢跑的话，怎么确保每一步清理都到位。漏掉任意一环，程序就从“健壮”滑向“缓慢腐烂”。

今天带大家了解了的相关知识，希望对你有所帮助；关于Golang的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~