答案。

问题的背景：

defer、panic和recover操作符是Go中管理执行流的重要机制。defer用于延迟执行函数，panic引发错误（紧急终止），而recover允许捕获紧急情况并继续执行。

问题：

在没有正确使用这些工具的情况下，正确地最终化资源和实现容错非常困难。函数的不可预测的终止、未释放的资源和错误时应用程序的不可控“退出”是错误使用时常见的问题。

解决方案：

正确使用defer确保即使在错误情况下也能安全地释放资源。panic是处理异常状况时的紧急终止机制，仅应在真正的特例中使用。recover允许在延迟执行的函数中“拯救”执行。

代码实例：

func riskyFunction() {
    defer func() {
        if r := recover(); r != nil {
            fmt.Println("在riskyFunction中恢复：", r)
        }
    }()
    fmt.Println("正在做一些工作...")
    panic("发生了一些坏事！")
}

func main() {
    riskyFunction()
    fmt.Println("在riskyFunction之后")
}

关键特性：

defer始终按相反的顺序在函数退出之前调用。即使在panic情况下也是如此。
recover仅在延迟函数内部有效。
panic终止当前goroutine的执行；如果没有通过recover捕获，则结束过程。

难题。

为什么recover在panic发生的同一函数内部无法工作？

只有当从defer函数中调用时，recover才会返回非零值（即捕获panic），如果直接调用recover，它总是返回nil。

代码示例：

func f() {
    panic("失败！")
    r := recover() // 不工作！
}

可以在panic之后调用defer并执行吗？

不可以。在panic之后，所有已注册的defer调用都将执行，但在panic之后的新defer将不会被调用，因为函数的执行已经“收缩”。

可以从另一个goroutine中的panic中恢复（recover）吗？

不可以，recover仅对当前goroutine中的panic有效。如果另一个goroutine发生panic并且没有在同一goroutine中调用recover，则应用程序将终止。

常见错误和反模式

使用panic来处理常规错误。
期望recover能够“捕获”代码中所有部分的panic。
混淆多个defer的调用顺序。

现实案例

消极案例

在项目中，所有错误都通过panic抛出，恢复处理仅在主函数中进行。这导致资源未关闭、部分数据丢失以及日志难以阅读。

优点：

快速开发，处理错误的代码较少。

缺点：

系统行为不可预测，频繁泄漏，调试困难。

积极案例

在每个关键部分使用defer来释放资源，panic仅用于真正的特例，recover用于隔离非关键部分的紧急情况。同时记录所有错误细节。