Go panicreturn 如何限定异常范围

“panicreturn”不是 Go 内置关键字，工程上通常指一种收敛模式：在明确的函数边界里使用命名返回值、defer 和 recover，把允许转换的 panic 变成 error 返回给调用方。它限定的不是整个进程，而是当前 goroutine 中这一层函数的责任范围。

最稳妥的做法是：业务输入和可预期失败直接返回 error；只有跨越内部实现边界、确实需要保护调用方时，才在边界函数中 recover，并保留 panic 的上下文。

先记住三点：recover 必须由 deferred function 直接调用；它不能跨 goroutine 捕获 panic；不该吞掉程序不变量被破坏的 panic。

panicreturn 到底限定了什么

Go 的 panic 会让当前函数停止普通执行，按栈展开并运行 defer；没有 recover 时，最终会让当前 goroutine 退出。panicreturn 只是把 recover 放在一个可命名的边界函数里，不会给 panic 增加新的语法或全局开关。

边界可以是解析器的公开入口、插件适配器、任务执行器或 HTTP 请求处理器。边界外只看见稳定的返回协议，边界内仍然可以用 panic 快速中止一段内部递归逻辑。

用命名返回值把 panic 转成 error

关键在于让 defer 修改命名返回值。下面的示例只收敛本函数执行期间的 panic，并把非 error 类型的 panic 也包装成 error：

func safeDecode(input []byte) (value map[string]any, err error) {
    // recover 必须直接出现在 deferred function 中，才能接住本 goroutine 的 panic。
    defer func() {
        if recovered := recover(); recovered != nil {
            // 保留原始值，便于调用方看到失败上下文；正常返回时不改写 err。
            err = fmt.Errorf("decode panic: %v", recovered)
            value = nil
        }
    }()

    // 这里代表可能在内部递归中 panic 的实现；公开边界统一返回 error。
    value = decodeInternal(input)
    return value, nil
}

注意两个细节：一是 recover() 不能塞进普通辅助函数，否则直接调用条件不成立；二是恢复后应把部分结果清零，避免调用方同时拿到“不完整的 value”和非 nil error。

哪些 panic 应该转换，哪些应该继续暴露

不要因为函数签名最后有 error 就自动吞掉所有 panic。可以先用这张决策表划边界：

Go 官方惯例也是：包内部可以用 panic 简化复杂实现，但对外 API 仍提供显式 error。换句话说，recover 是边界保护，不是错误处理的替代品。

goroutine、资源和日志不能越过边界

每个 goroutine 都要在自己的入口设置保护点。主 goroutine 的 recover 接不到子 goroutine 的 panic；如果任务执行器希望把异常变成任务结果，应把启动逻辑包起来：

func runTask(fn func()) (err error) {
    // 任务边界只负责把 panic 记录为失败，不改变其他 goroutine 的状态。
    defer func() {
        if recovered := recover(); recovered != nil {
            err = fmt.Errorf("task panic: %v", recovered)
        }
    }()
    fn()
    return nil
}

go func() {
    // 子 goroutine 必须在自身入口调用边界函数。
    if err := runTask(work); err != nil {
        log.Printf("task failed: %v", err) // 生产代码可替换为带 request/task ID 的结构化日志。
    }
}()

资源清理仍用各自的 defer，例如文件、锁和临时目录的释放要在获得资源后立即登记。recover 的 defer 与清理 defer 按后进先出执行，日志里应包含任务 ID、阶段和原始 panic 值，避免只留下“失败”两个字。

用测试确认异常没有越界

测试至少覆盖正常返回、panic(error)、运行时 panic 和 Go 1.21 起的 panic(nil) 行为。断言重点不是“所有情况都返回 nil”，而是结果值、error、日志和 goroutine 生命周期是否符合边界协议。

一个实用检查清单是：正常路径保持原值；恢复路径返回零值和带上下文的 error；recover 没有放在间接函数里；子 goroutine 有独立保护点；不变量破坏没有被悄悄吞掉。这样限定后，panicreturn 才是可审查的 API 设计，而不是隐藏异常的黑盒。

相关问题

recover 能捕获另一个 goroutine 的 panic 吗？不能。必须在发生 panic 的同一个 goroutine 中设置 deferred recover。

有 error 返回值就应该 recover 吗？不应该。可预期失败直接返回 error；recover 只放在需要隔离实现细节的边界。

panic(nil) 能用 recovered != nil 判断吗？Go 1.21 起 panic(nil) 会触发一个不同的运行时 panic，因此应按目标 Go 版本测试，不要把旧版本经验当成统一结论。