Go panic recover 为什么在外层函数接不到

Go 的外层函数接不到 panic，最常见的原因是 panic 发生在另一个 goroutine。recover 不是进程级兜底开关：它必须由正在展开 panic 的同一 goroutine 中的延迟函数直接调用。普通同步调用的外层 defer 可以恢复内层 panic，启动子 goroutine 的父函数却不能隔空恢复子任务。

Go 官方地址：https://go.dev/

先看外层和任务是否属于同一 goroutine

讨论任务包装函数时，我更愿意先标出 goroutine 边界，而不是先加一个大的 recover。代码缩进很容易让人误以为“写在外面”就保护了里面；真正相关的是运行时的调用栈。这也是我倾向于把恢复放在任务执行包装器中的原因，而不是让上层入口承担所有异常。

设想一个导出任务：StartExport 在父 goroutine 中启动 Worker，Worker 调用 BuildReport。即使 StartExport 注册了父级 defer，Worker 的 panic 也只在子 goroutine 的栈上展开。父 goroutine 边界包括 StartExport、父级 defer；子 goroutine 边界包括 Worker、BuildReport、任务 panic。StartExport 与 Worker 有启动关联，Worker 与 BuildReport 有调用关联，BuildReport 与任务 panic 有触发关联，但父级 defer 没有跨边界的恢复能力。

规则可查官方语言规范：https://go.dev/ref/spec#Handling_panics。本文的小实验使用人为触发的普通 panic，不涉及进程退出、不可恢复的运行时致命错误或额外后台任务。

用同步调用确认恢复位置

在自己的空目录保存下面代码为 main.go，可以先理解同步调用为什么能够被包装器恢复。本文给出源码与结果判断，不冒充已经执行过的日志。

package main

import "fmt"

func BuildReport() {
    panic("报表模板缺少字段") // 人为触发，用来观察普通 panic 的恢复边界。
}

func guarded() (err error) {
    defer func() {
        // recover 必须直接在这个延迟函数内调用。
        if value := recover(); value != nil {
            err = fmt.Errorf("报表失败: %v", value)
        }
    }()
    BuildReport() // 普通调用，与 guarded 在同一个 goroutine。
    return nil
}

func main() {
    fmt.Println(guarded()) // 应检查返回错误，而不是期待从 panic 处继续。
}

这里 defer 在 BuildReport 调用前完成注册。若没有 panic，函数正常返回 nil；若触发 panic，延迟函数将命名返回值 err 设为失败，guarded 返回调用方。恢复后不是跳回 BuildReport 的 panic 下一行，也不是继续 guarded 中 BuildReport 后面的普通语句。

另一个我会优先检查的细节是辅助函数：defer func() { helper() }() 中若 recover 在 helper 内调用，就不满足“延迟函数直接调用 recover”。可以在延迟函数中取到值，再调用 helper(value) 做记录。直接写 defer helper() 则不同：helper 本身是延迟执行的函数，可以在其内部直接调用 recover。还要避免 defer log.Println(recover())，这里参数在注册 defer 时求值，recover 调用并不是发生在延迟函数体中。官方说明见 https://go.dev/blog/defer-panic-and-recover。

把恢复放进子任务的执行边界

我更喜欢让任务包装器返回一个明确 Result：既有正常 error 的位置，也有 PanicValue 与 Stack 的位置。调用方收到失败后可决定记录、停止批次或返回失败响应，不把“进程暂时没退出”当成业务成功。下面是另一份独立完整示例，请单独保存，不能与上一份含 main 的程序直接拼接。

package main

import (
    "fmt"
    "runtime/debug"
)

type Result struct {
    Err        error
    PanicValue interface{}
    Stack      []byte
}

func runTask(task func() error) (result Result) {
    defer func() {
        // 在执行 task 的同一 goroutine 中恢复，并保留原始值与堆栈。
        if value := recover(); value != nil {
            result.PanicValue = value
            result.Stack = debug.Stack()
            result.Err = fmt.Errorf("导出任务 panic: %v", value)
        }
    }()
    result.Err = task() // 普通错误原样传回，不需要 panic 才表示失败。
    return
}

func main() {
    results := make(chan Result, 1) // 单任务单结果；缓冲避免发送依赖立即接收。
    go func() {
        result := runTask(func() error {
            panic("导出字段缺失") // 示范可恢复的任务异常。
        })
        results 

任务包装分组中的 runTask、延迟恢复函数、任务函数属于同一执行边界：runTask 调用任务函数并注册延迟恢复函数，后者为 Result 设置失败信息。结果交付分组中的 Result、results、父函数 main 建立值传递关系。父函数处理 Result，不参与子任务栈上的恢复。

debug.Stack 保存调用它的 goroutine 堆栈，不是自动收集所有任务。官方定义：https://pkg.go.dev/runtime/debug#Stack。堆栈用于内部诊断，可能含代码路径，不能未经处理直接返回给公开 API 客户端。示例只有一个发送者和一个结果，接收方按固定数量接收，不需要靠关闭通道通知结束；扩展成多任务后必须重新设计结果数量、取消与关闭责任。

核对返回值而不是期待继续执行

# 在只保存其中一份 main.go 的实验目录运行，观察错误与等待行为。
go run main.go

第一份应观察 guarded 返回失败；第二份应观察主函数收到 Err 与堆栈信息，而不是打印“任务完成”。这是由示例逻辑推导的预期，具体输出和堆栈内容以你自己的执行为准。不要为了观察跨 goroutine 失败，把它与正常案例放在同一个测试进程并认为一定能兜住；未恢复的子任务 panic 可能使整个程序结束。

扩展测试时分别覆盖任务正常返回、返回普通 error、触发 panic。三个分支都应产生正确的 Result，并检查完成通知是否丢失。包装器仅覆盖 task 的同步调用链：task 自己再启动的新 goroutine 不受此处 recover 保护。恢复后的 return 也不表示业务修改自动回滚。

决定哪些失败不该被吞掉

对我来说，recover 的明显代价是可能让损坏状态继续存在。一个任务写完半份文件、改完一半内存状态后 panic，恢复只能改变控制流，不能撤销这些副作用。事务、临时文件替换、幂等标识和清理责任仍要在业务层设计。defer 可以释放确定的资源，但不能凭空保证一致性。

这类包装适合有明确单任务输入输出、可报告失败的导出或插件执行边界，不是所有函数都加 recover 的理由。我会把“是否能安全结束这项任务”作为采用条件，把“出了 panic 也要继续运行”视为需要论证的业务选择。

recover 为什么返回 nil？

检查当前 goroutine 是否正在 panic，以及是否由延迟函数直接调用。正常返回时执行 defer，也会得到 nil。当前默认语义下 panic(nil) 会产生非 nil 的运行时 panic 值；历史兼容设置有差异，不要据旧经验概括所有环境。

恢复以后错误为什么还是 nil？

可能只打印了 panic，没有写入返回结果。示例采用命名 Result，由延迟函数更新；若恢复失败却返回成功标志，调用方仍会误判。

外层中间件能保护所有后台任务吗？

不能。中间件只覆盖自己的执行边界，新 goroutine 应有独立的任务包装与失败通知约定。