Go 中的 recover() 函数仅在作为由该恐慌引起的回收过程的一部分正在执行的延迟函数中直接调用时才能停止恐慌。当你在一个被延迟的闭包调用的辅助函数内部调用 recover() 时，运行时检测发现当前 goroutine 的执行帧不是与活动恐慌相关的顶层延迟帧。
// 这个模式无法恢复： func handlePanic() { if r := recover(); r != nil { log.Println("Recovered:", r) } } func risky() { defer handlePanic() // recover() 在这里返回 nil panic("error") }
runtime 通过 g.recover 字段维护此检查，该字段存储控制恢复所需的延迟函数的堆栈帧指针。当 recover() 执行时，它将当前堆栈指针与此存储值进行比较；如果它们不匹配，recover() 返回 nil，而恐慌将继续向上传播至堆栈。这种架构约束确保了恢复逻辑保持明确和局部化，防止深层次嵌套的辅助函数意外吞噬应传播到更高层恢复处理程序的恐慌。
在一个处理成千上万并发 goroutines 的高吞吐量微服务中，我们实施了一种集中式恐慌恢复机制，以防止由于格式错误的请求导致服务器崩溃。最初的实现使用了一个封装了日志和度量的实用函数 SafeRecover()，开发人员在每个处理程序开始时使用 defer SafeRecover() 来延迟这个函数。然而，在一次生产事故中涉及到处理请求的除零错误，尽管有明显的恢复机制，服务仍然崩溃，表明恐慌没有被拦截，因为 recover() 嵌套在辅助函数内部，而不是直接调用。
我们首先考虑要求开发人员在每个函数入口点手动编写 defer func() { if r := recover(); r != nil { ... } }()。这种方法提供了对 recover() 的直接访问，以确保运行时合规，但它引入了大量样板代码，并依赖于人类的一致性，使其在大型团队中容易出错，并在代码审查期间难以强制执行。
第二种方法涉及修改 SafeRecover() 以接受一个闭包作为参数，并在调用辅助逻辑之前在传入的函数内部执行 recover()。虽然这在技术上满足了要求，通过将 recover() 放置于延迟帧中，但它创建了一个尴尬的 API，使处理程序必须将其恢复逻辑作为回调传递，复杂化了控制流并降低了可读性，同时增加了不必要的间接性。
最终，我们选择了第三种方法：在 HTTP 路由级别实现一个中间件包装器，直接在中间件的延迟闭包中执行 defer func() { if r := recover(); r != nil { logAndMetrics(r) } }()。这个解决方案确保 recover() 在正确的堆栈深度被调用，同时保持关注点清晰的分离，在随后的混乱测试中实现了 100% 的恐慌拦截率，并在接下来的一个季度内零崩溃循环。
为什么在没有活动恐慌时在延迟函数外调用 recover() 会返回 nil？
在延迟执行上下文之外，recover() 查询当前 goroutine 的恐慌状态，发现没有活动的恐慌记录，导致其立即返回 nil。细微之处在于 recover() 检查当前函数是否作为延迟堆栈回收的一部分执行，而不仅仅是检查程序某处是否存在恐慌。当从正常执行路径调用时，运行时发现 goroutine 结构上的 _panic 字段为 nil，并返回 nil，没有副作用，防止误用该机制。
当同一 goroutine 中的多个延迟函数调用 recover() 并且为什么只有第一个成功时，会发生什么？
当发生恐慌时，Go 以 LIFO 顺序执行延迟函数，第一个调用 recover() 的延迟函数原子性地清除 goroutine 内部 _panic 链表中的活动恐慌状态。后续调用 recover() 的延迟函数发现恐慌状态已经得到解决，导致它们返回 nil 而不是原始的恐慌值。这种设计确保了确定性的恐慌处理，其中最内层的恢复范围优先，阻止冗余的恢复尝试，从而可能混淆错误传播逻辑，一旦堆栈恢复正常执行。
panic(nil) 的行为与 panic("nil") 或 panic(0) 有何不同，为什么 Go 1.21 改变了这种行为？
在 Go 1.21 之前，调用 panic(nil) 导致运行时将恐慌值视为特殊哨兵，recover() 将其视为 nil 返回，使其与没有恐慌可处理的 recover() 调用不可区分，并造成危险的模糊。在 Go 1.21 及以后的版本中，运行时自动将 nil 恐慌值转换为包含字符串 "runtime error: panic called with nil argument" 的非 nil 运行时错误，确保 recover() 总是返回非 nil 值当它成功拦截恐慌时。这一变化消除了错误处理代码中的歧义，使开发人员能够放心地检查 if r := recover(); r != nil，知道返回的 nil 真正表示没有发生恐慌。