17370845950

goroutine 的 panic 不会自动传播，必须每个都自己 recover：其 panic 是局部隔离的，主 goroutine 的 recover 无法捕获子 goroutine 的 panic，需在每个子 goroutine 内部用 defer+匿名函数显式 recover 并处理资源清理。

goroutine 的 panic 不会自动传播，必须每个都自己 recover

Go 中协程（goroutine）是独立的执行单元，它的 panic 是局部的、隔离的。主 goroutine 或其他 goroutine 里的 defer + recover 完全捕获不到——这不是 bug，是设计使然。如果你在 main 函数里写了个 defer func() { recover() }()，然后启动一个子 goroutine 并让它 panic，程序照样崩溃，且那个 recover 什么也捞不到。

• 子 goroutine panic 后会静默退出，不通知任何人，可能造成连接未关闭、文件未 flush、channel 未 close 等资源泄漏
• HTTP handler 里 panic（比如 Gin 默认没关 recover 中间件），客户端直接断连，看不到错误响应
• 想“全局兜底”？不行。必须让每个可能出错的 goroutine 自己配 defer + recover

标准 recover 写法：defer 匿名函数 + 非内联调用

recover 只有在 defer 延迟执行的函数中才有效，而且该函数不能被编译器内联优化掉（否则 recover 就失效了）。最稳妥的方式是用带空参数的匿名函数，避免 Go 编译器“自作聪明”：

go func() {
    defer func() {
        if r := recover(); r != nil {
            log.Printf("goroutine panicked: %v", r)
            // 这里做清理：close(ch), http.CloseNotifier(), etc.
        }
    }()
    // 可能 panic 的业务逻辑
    riskyOperation()
}()

• 必须把 defer 放在 riskyOperation() 之前，否则 panic 发生时 defer 还没注册
• 别写 defer recover() —— 这是语法错误，recover 不是普通函数，不能直接 defer 调用
• 别用命名函数替代匿名函数（如 defer handlePanic()），除非你明确加了 //go:noinline 注释，否则容易被内联导致 recover 返回 nil

别指望 recover 后自动继续执行原逻辑

recover 的作用只是让 goroutine 从 panic 状态中“软着陆”，它不会回滚栈、也不会跳回去继续执行 panic 后面的代码。一旦 panic 触发，当前函数后续语句全部跳过，控制权直接交给 defer 链。

• 下面这段代码中，fmt.Println("never runs") 永远不会打印：
• defer func() { recover() }()
• panic("boom")
• fmt.Println("never runs")

所以 recover 后你要主动决定流程：记录

日志、返回错误、重试、关闭资源、甚至调用 os.Exit(1) —— 但这些都得你自己写，Go 不会替你续上。

封装 safeGo：统一处理子 goroutine panic 的最小实践

重复写 go func() { defer ... }() 很啰嗦，也容易漏。推荐封装一个轻量级的 safeGo 工具函数，作为团队内部约定：

func safeGo(f func()) {
    go func() {
        defer func() {
            if r := recover(); r != nil {
                log.Printf("panic in goroutine: %v (stack: %s)", r, debug.Stack())
            }
        }()
        f()
    }()
}

• 调用方式简洁：safeGo(func() { doSomethingRisky() })
• 注意：它只解决 panic 捕获，不解决竞态、死锁、context 超时等并发问题
• 如果业务需要更精细控制（比如 panic 后发信号、上报 metrics、按错误类型分流），就得在 defer 里扩展逻辑，而不是依赖“一次封装走天下”

真正难的从来不是写对 recover，而是判断 panic 后状态是否一致、资源是否可安全释放、下游是否已收到部分数据——这些没法靠语法糖解决，得结合业务逻辑一层层推演。