Golang协程panic处理与并发限制

Golang中panic不会跨goroutine传播，这既是保障并发服务健壮性的关键设计，也带来了必须在每个潜在panic的goroutine内部独立使用defer+recover捕获、正确调用recover（仅限defer函数内直接调用）、及时清理资源防止泄漏、并严禁在goroutine中使用log.Fatal或os.Exit等易被忽视却致命的实践要点；真正决定系统稳定性的，往往不是能否捕获panic，而是recover后是否做了彻底的资源释放、状态清理与协程优雅退场——一个未关闭的channel、一个未stop的timer、一次遗漏的通知，都可能悄然演变为压垮服务的goroutine泄漏和OOM危机。

panic 不会跨 goroutine 传播

Go 的 panic 只在当前 goroutine 内崩溃，不会“冒泡”到启动它的父 goroutine 或其他 goroutine。这是设计使然，不是 bug —— 否则一个子协程出错就 kill 掉整个程序，根本没法做健壮的并发服务。

常见错误现象：recover 在主 goroutine 里写得再全，也抓不到子 goroutine 里的 panic；日志里只看到 panic: xxx 加一堆 goroutine stack，但程序没退出、也没触发你写的 recover 逻辑。

• 必须在每个可能 panic 的 goroutine 内部单独用 defer + recover
• 不要指望在 go func() { ... }() 外面包一层 defer/recover —— 它俩不在同一个执行流里
• 如果 goroutine 是通过第三方库启动（比如 http.Server 启的 handler），得确认它是否已内置 recover，否则你的 panic 会直接打印到 stderr 并丢失上下文

recover 必须紧挨 defer 才有效

recover 只有在 defer 函数中调用才起作用，而且不能被包裹在更深的函数调用里（比如传给闭包、或者放在 if 分支里但分支没执行）。

使用场景：处理网络请求时，避免单个请求 panic 导致整个 HTTP server 挂掉。

go func() {
    defer func() {
        if r := recover(); r != nil {
            log.Printf("request panicked: %v", r)
        }
    }()
    // 这里可能 panic，比如 map 写 nil、索引越界
    processRequest()
}()

• 写成 defer recover() 是无效的 —— recover 立即执行，此时还没 panic
• 写成 defer func() { recover() }() 也不行 —— 没接返回值，等于白写
• 如果 recover 被包在 if err != nil { recover() } 里，而 panic 发生时 err 是 nil，那就彻底漏抓

goroutine 泄漏比 panic 更隐蔽

很多人专注 catch panic，却忽略 recover 后的资源清理。比如 goroutine 里开了 timer、占了 channel、持有了 mutex，recover 之后没关、没释放、没 close，这个 goroutine 就永远卡住，变成泄漏。

性能影响：泄漏的 goroutine 不会自动 GC，堆栈内存持续占用，runtime.NumGoroutine() 持续上涨，最终 OOM。

• recover 后务必检查：channel 是否该 close、timer 是否该 stop、锁是否该 unlock、文件/连接是否该 close
• 别在 defer 里只写 recover()，后面跟上 cleanup 逻辑，或用命名返回值封装清理行为
• 用 pprof/goroutines 定期看 goroutine 堆栈，重点查 select {}、chan receive、semacquire 卡住的长期存活 goroutine

log.Fatal 和 os.Exit 在 goroutine 里会杀整个进程

这不是 panic，但效果更猛：只要任意 goroutine 执行 log.Fatal 或 os.Exit，整个进程立刻终止，连 main 函数的 defer 都不执行。

容易踩的坑：把调试用的 log.Fatal("debug") 误留在生产代码的 goroutine 中；或第三方库内部调用了 os.Exit（比如某些 CLI 工具库）。

• 永远不要在 goroutine 里用 log.Fatal、os.Exit、panic（除非你明确要终结进程）
• 替代方案：返回 error、发信号到控制 channel、调用自定义的 shutdown hook
• CI 阶段可用静态检查工具（如 staticcheck）配规则 SA1017 检出 goroutine 中的 os.Exit

真正难的不是写 recover，而是判断该不该 recover、recover 之后该不该继续跑、以及怎么让失败的 goroutine 彻底退场而不是变成僵尸。很多线上事故，根子不在 panic 本身，而在 recover 后忘了关连接、忘了通知上游、忘了更新状态。

以上就是《Golang协程panic处理与并发限制》的详细内容，更多关于的资料请关注golang学习网公众号！