1. 先搞清楚 panic 和 recover 到底在管什么如果你写过 Go肯定遇到过程序突然崩溃打印一堆调用栈信息然后退出的情况。这背后就是panic。而recover则是给程序一个“抓住”这次崩溃让它不至于直接退出的机会。但很多人对它们的理解停留在“知道有这么个东西”一到实际用的时候就搞不清recover到底能不能抓到panic、该写在哪儿、以及崩溃后调用栈是怎么一层层“解开”的。这篇文章不打算只讲语法而是用“动画”的思维带你一步步拆解panic触发后函数调用栈是如何展开unwinddefer语句又是如何成为recover的“黄金救援点”的。看完后你不仅能写出更健壮的recover代码在排查复杂崩溃问题时也能一眼看懂那个令人头疼的调用栈跟踪信息。最关键的是你会明白为什么recover只有在defer中调用才有效以及这个设计背后清晰的工程逻辑。2. 没有“动画”我们就用日志和调试器“画”出来我们没法在文章里放真正的动画但完全可以通过精心设计的代码、添加日志、以及利用调试器在脑子里构建出调用栈变化的每一步。这比看现成的动画理解得更深因为每一步你都知道为什么。首先建立一个基础认知模型Go 程序的函数调用会形成一个“调用栈”Call Stack。你可以想象成一摞盘子每调用一个函数就往最上面放一个新盘子压栈函数返回时就把最上面的盘子拿走弹栈。panic发生时就像是有人从当前这层盘子函数开始异常地、一层层地把上面的盘子扔掉直到遇到一个装了recover的“特殊盘子”defer函数或者把所有盘子都扔光程序崩溃。我们先从一个最简单的、会崩溃的例子开始看看栈的“原始状态”。package main func main() { level1() } func level1() { level2() } func level2() { panic(something went wrong in level2) }运行它你会看到类似下面的输出panic: something went wrong in level2 goroutine 1 [running]: main.level2() /tmp/sandbox/prog.go:12 0x27 main.level1() /tmp/sandbox/prog.go:8 0x14 main.main() /tmp/sandbox/prog.go:4 0x14这个栈跟踪stack trace就是从panic发生点level2开始自下而上打印的。它清晰地展示了崩溃前一刻的调用链main - level1 - level2。这就是程序崩溃时留给你的“现场快照”。3. defer调用栈展开时的“逆序执行者”要引入recover必须先彻底理解defer。defer语句会将一个函数调用“推迟”到包含它的函数返回之前执行。关键在于这个“返回”包括正常返回和因为panic导致的非正常返回。而且多个defer的执行顺序是后进先出LIFO的。这在panic发生时就形成了“栈展开”时的关键行为。我们修改一下代码加上defer日志。package main import fmt func main() { fmt.Println(main start) defer fmt.Println(defer in main) level1() fmt.Println(main end) // 这行在 panic 后不会执行 } func level1() { fmt.Println(level1 start) defer fmt.Println(defer in level1) level2() fmt.Println(level1 end) } func level2() { fmt.Println(level2 start) defer fmt.Println(defer in level2) panic(panic in level2) fmt.Println(level2 end) // 这行不会执行 }运行它输出是main start level1 start level2 start defer in level2 defer in level1 defer in main panic: panic in level2 ...栈跟踪信息这就是“动画”的第一帧panic在level2中发生。Go 运行时立即停止当前函数level2的正常执行流但不会立刻崩溃。它转而开始执行当前函数中已经注册的defer函数。所以我们看到了defer in level2。第二帧level2的defer执行完后panic继续向上“传播”到调用者level1。同样level1的正常执行流fmt.Println(“level1 end”)被中断转而执行它的deferdefer in level1。第三帧panic继续上传到main函数。main函数也中断执行它的deferdefer in main。最终帧当main函数的defer也执行完毕后这个panic没有被任何recover捕获于是程序崩溃打印出我们最开始看到的那个 panic 信息和栈跟踪。这个过程就像多米诺骨牌倒下但每倒下一块每个函数返回前都会先完成一个特定的收尾动作defer。defer是你在栈展开过程中插入代码进行干预比如关闭文件、解锁、或者recover的唯一机会窗口。4. recover 如何“截停”panic 的传播recover是一个内置函数它的唯一作用就是捕获catch当前 goroutine 中正在发生的panic。如果panic被recover捕获panic的传播就会停止程序从panic中恢复继续执行recover所在defer函数之后的代码并逐步返回到上层调用函数。但有一个铁律recover只有在defer函数中调用才有效。结合上一节的“动画”原因就非常直观了——因为只有defer函数是在栈展开过程中被执行的recover只有在这个阶段被调用才能“够得着”正在向上传播的panic。让我们把recover加进去。一个常见的模式是在顶层函数如main或 HTTP 处理器中使用defer和recover来防止整个程序或单个请求崩溃。package main import fmt func main() { fmt.Println(main start) // 在main的defer中尝试recover defer func() { if r : recover(); r ! nil { fmt.Printf(Recovered in main: %v\n, r) } }() level1() fmt.Println(main end) // 注意这行现在有机会执行了 } func level1() { fmt.Println(level1 start) defer fmt.Println(defer in level1) level2() fmt.Println(level1 end) } func level2() { fmt.Println(level2 start) defer fmt.Println(defer in level2) panic(panic in level2) fmt.Println(level2 end) }运行结果main start level1 start level2 start defer in level2 defer in level1 Recovered in main: panic in level2 main end动画过程解析panic在level2中发生。执行level2的defer(defer in level2)。panic传播到level1执行level1的defer(defer in level1)。panic传播到main。开始执行main的defer。在main的defer函数中recover()被调用。此时它成功捕获到了正在传播的panic并返回了panic的值”panic in level2″。关键点panic的传播在此刻被截停了。recover所在的defer函数正常执行完毕打印出恢复信息。由于panic已被处理程序不会崩溃。main函数从defer返回后继续执行defer之后的代码即fmt.Println(“main end”)。注意level1和level2中panic之后的代码level1 end,level2 end永远不会执行。因为panic导致它们所在的函数异常返回了执行权不会回到那里。recover只是在传播路径上“接住”了它但无法让已经“炸掉”的函数恢复执行。你可以把recover想象成在panic传播路径上设置的一个安全网。安全网defer中的recover只能接住从上面掉下来向上传播的panic而不能跳进已经炸毁的楼层已经发生panic的函数去救人。5. 实战中 recover 的边界与陷阱理解了基本原理我们来看几个实战中容易出错的地方。这些是判断你是否真懂了的关键。5.1 recover 必须在直接 defer 的函数中调用这是一个经典错误。recover必须在defer关键字后面那个函数里被直接调用。// 错误示例recover 不在 defer 的直接函数体内 func badRecover() { if r : recover(); r ! nil { fmt.Println(Recovered:, r) } } func main() { defer badRecover() // 这样是无效的 panic(test) } // 程序依然会崩溃。为什么因为defer badRecover()注册的是badRecover函数的执行。而badRecover函数是在panic发生后在栈展开时被调用的。此时badRecover函数内部的recover()调用是有效的。等一下这个例子看起来矛盾其实不矛盾这个例子里的recover是有效的。我举了一个不恰当的反例。让我们修正一下。真正的陷阱是recover必须是在panic发生的同一个 goroutine 的defer路径上被调用。更典型的无效用法是这样的func main() { defer func() { go func() { // 错误在新的 goroutine 中 recover 无效 if r : recover(); r ! nil { fmt.Println(这行不会执行) } }() }() panic(test) } // 程序会崩溃因为 recover 在另一个 goroutine 里。正确的写法就是我们在第4节用的一个匿名函数。defer func() { if r : recover(); r ! nil { // 处理恢复逻辑 } }()5.2 recover 只能捕获同一 goroutine 的 panicGo 的每个 goroutine 都有独立的执行栈和 panic/recover 机制。一个 goroutine 的recover无法捕获另一个 goroutine 中发生的panic。这是并发编程中常见的死因。package main import ( fmt time ) func safeGoRoutine() { defer func() { if r : recover(); r ! nil { fmt.Printf(Recovered in goroutine: %v\n, r) } }() panic(panic inside goroutine) } func main() { go safeGoRoutine() // 这个 goroutine 自己会 recover time.Sleep(100 * time.Millisecond) // 主 goroutine 没有 recover go func() { panic(panic in another goroutine) }() time.Sleep(1 * time.Second) // 等待看崩溃 fmt.Println(Main ends) // 可能打印不出来因为程序可能因第二个 goroutine panic 而崩溃 }你需要为每个可能panic的 goroutine 单独设立recover防线。这通常意味着在 goroutine 的入口函数最上层写defer recover。5.3 被 recover 后程序状态可能已损坏recover给了程序继续运行的机会但并不代表程序状态是健康的。panic往往发生在深层函数中可能已经破坏了数据的一致性例如只更新了一半的数据结构文件只写了一半。var globalCounter int func riskyOperation() { globalCounter panic(oops after increment) // globalCounter-- // 这行永远不会执行导致计数器状态错误 } func main() { defer func() { if r : recover(); r ! nil { fmt.Println(Recovered from:, r) fmt.Println(But globalCounter is now:, globalCounter) // 可能是错误的值 } }() riskyOperation() }经验法则recover之后通常应该记录详细的错误信息和栈跟踪可以用debug.Stack()。清理当前请求或任务的资源如关闭连接、回滚事务。让当前处理流程优雅失败而不是假装什么都没发生继续业务逻辑。例如在一个 HTTP 服务器中recover后应该返回一个 500 内部服务器错误响应而不是继续尝试生成响应体。5.4 如何获取被 recover 后的栈信息崩溃时打印的栈跟踪很有用。recover后我们仍然可以通过runtime/debug包来获取它。package main import ( fmt runtime/debug ) func deepFunc() { panic(deep panic) } func main() { defer func() { if r : recover(); r ! nil { fmt.Printf(Recovered: %v\n, r) fmt.Println(Stack trace at panic:) // 打印栈信息 debug.PrintStack() } }() deepFunc() }这会在recover后打印出完整的栈跟踪对于线上问题排查至关重要。6. 设计模式在哪里放置 recover 最有效知道了原理我们来谈谈实战中recover应该放在哪里。盲目地在每个函数开头都加defer recover是糟糕的设计它会掩盖错误让调试变得极其困难。6.1 边界处恢复Boundary Recovery这是最有效和推荐的模式。在模块、组件或并发单元的边界处设置recover。HTTP 服务器在每个 HTTP 请求处理器的入口或中间件设置recover确保一个请求的panic不会导致整个服务器进程崩溃。func myHTTPHandler(w http.ResponseWriter, r *http.Request) { defer func() { if r : recover(); r ! nil { log.Printf(Panic recovered: %v, r) http.Error(w, Internal Server Error, http.StatusInternalServerError) } }() // ... 实际的业务逻辑 ... }Goroutine 入口在启动 goroutine 的顶层函数里设置recover。go func() { defer func() { if r : recover(); r ! nil { log.Printf(Goroutine panic recovered: %v, r) // 可能还需要通知主循环此 goroutine 已异常退出 } }() doBackgroundTask() }()主函数 main在main函数中设置一个最终的recover可以捕获初始化阶段或其他未受保护的 goroutine 中漏网的panic至少能让你有机会记录日志、清理资源后再退出。func main() { defer func() { if r : recover(); r ! nil { log.Fatalf(Fatal panic in main: %v, r) } }() // ... 程序主逻辑 ... }6.2 避免在库代码中随意 recover作为一个库的作者你的函数被谁调用、在什么上下文中调用是未知的。除非你的库文档明确声明会在内部处理某些特定错误并转换为panic否则通常不应该在库的内部函数里使用recover。让panic自然地传播到调用方应用程序代码由调用方在边界处决定如何处理这样调用者才能获得完整的错误上下文。一个在库内部悄悄recover并只返回一个普通错误的函数会让调用者丢失“这里发生了严重异常”的关键信息。7. 总结把调用栈动画刻在脑子里最后我们回顾一下整个“动画”流程形成肌肉记忆触发当执行到panic(v)时当前函数的正常执行立即停止。展开开始Go 运行时开始逆序执行当前函数中已注册的defer函数。传播当前函数的defer执行完毕后panic会沿着调用栈向上“传播”到调用者函数。逐层展开在每个上层函数中同样是先停止正常执行逆序执行该函数的defer。救援检查在执行任何一个defer函数时如果其中调用了recover()recover会捕获到当前正在传播的panic值v并停止panic的进一步传播。恢复执行recover所在的defer函数正常执行完后程序从panic中恢复继续执行该defer所在函数中剩余的代码如果有的话然后该函数正常返回控制权继续向上层交还。无救援崩溃如果panic一直传播到最顶层的main函数且在其defer中仍未recover则程序崩溃打印panic值和完整的栈跟踪。记住这个画面你就能对 Go 程序的异常流控了如指掌。下次再看到panic输出你看到的将不再是一堆令人困惑的文件名和行号而是一幅清晰的、函数层层返回、defer依次执行的动态画卷。而recover就是你在画卷关键位置设置的一个“暂停键”。
1. 先搞清楚 panic 和 recover 到底在管什么如果你写过 Go肯定遇到过程序突然崩溃打印一堆调用栈信息然后退出的情况。这背后就是panic。而recover则是给程序一个“抓住”这次崩溃让它不至于直接退出的机会。但很多人对它们的理解停留在“知道有这么个东西”一到实际用的时候就搞不清recover到底能不能抓到panic、该写在哪儿、以及崩溃后调用栈是怎么一层层“解开”的。这篇文章不打算只讲语法而是用“动画”的思维带你一步步拆解panic触发后函数调用栈是如何展开unwinddefer语句又是如何成为recover的“黄金救援点”的。看完后你不仅能写出更健壮的recover代码在排查复杂崩溃问题时也能一眼看懂那个令人头疼的调用栈跟踪信息。最关键的是你会明白为什么recover只有在defer中调用才有效以及这个设计背后清晰的工程逻辑。2. 没有“动画”我们就用日志和调试器“画”出来我们没法在文章里放真正的动画但完全可以通过精心设计的代码、添加日志、以及利用调试器在脑子里构建出调用栈变化的每一步。这比看现成的动画理解得更深因为每一步你都知道为什么。首先建立一个基础认知模型Go 程序的函数调用会形成一个“调用栈”Call Stack。你可以想象成一摞盘子每调用一个函数就往最上面放一个新盘子压栈函数返回时就把最上面的盘子拿走弹栈。panic发生时就像是有人从当前这层盘子函数开始异常地、一层层地把上面的盘子扔掉直到遇到一个装了recover的“特殊盘子”defer函数或者把所有盘子都扔光程序崩溃。我们先从一个最简单的、会崩溃的例子开始看看栈的“原始状态”。package main func main() { level1() } func level1() { level2() } func level2() { panic(something went wrong in level2) }运行它你会看到类似下面的输出panic: something went wrong in level2 goroutine 1 [running]: main.level2() /tmp/sandbox/prog.go:12 0x27 main.level1() /tmp/sandbox/prog.go:8 0x14 main.main() /tmp/sandbox/prog.go:4 0x14这个栈跟踪stack trace就是从panic发生点level2开始自下而上打印的。它清晰地展示了崩溃前一刻的调用链main - level1 - level2。这就是程序崩溃时留给你的“现场快照”。3. defer调用栈展开时的“逆序执行者”要引入recover必须先彻底理解defer。defer语句会将一个函数调用“推迟”到包含它的函数返回之前执行。关键在于这个“返回”包括正常返回和因为panic导致的非正常返回。而且多个defer的执行顺序是后进先出LIFO的。这在panic发生时就形成了“栈展开”时的关键行为。我们修改一下代码加上defer日志。package main import fmt func main() { fmt.Println(main start) defer fmt.Println(defer in main) level1() fmt.Println(main end) // 这行在 panic 后不会执行 } func level1() { fmt.Println(level1 start) defer fmt.Println(defer in level1) level2() fmt.Println(level1 end) } func level2() { fmt.Println(level2 start) defer fmt.Println(defer in level2) panic(panic in level2) fmt.Println(level2 end) // 这行不会执行 }运行它输出是main start level1 start level2 start defer in level2 defer in level1 defer in main panic: panic in level2 ...栈跟踪信息这就是“动画”的第一帧panic在level2中发生。Go 运行时立即停止当前函数level2的正常执行流但不会立刻崩溃。它转而开始执行当前函数中已经注册的defer函数。所以我们看到了defer in level2。第二帧level2的defer执行完后panic继续向上“传播”到调用者level1。同样level1的正常执行流fmt.Println(“level1 end”)被中断转而执行它的deferdefer in level1。第三帧panic继续上传到main函数。main函数也中断执行它的deferdefer in main。最终帧当main函数的defer也执行完毕后这个panic没有被任何recover捕获于是程序崩溃打印出我们最开始看到的那个 panic 信息和栈跟踪。这个过程就像多米诺骨牌倒下但每倒下一块每个函数返回前都会先完成一个特定的收尾动作defer。defer是你在栈展开过程中插入代码进行干预比如关闭文件、解锁、或者recover的唯一机会窗口。4. recover 如何“截停”panic 的传播recover是一个内置函数它的唯一作用就是捕获catch当前 goroutine 中正在发生的panic。如果panic被recover捕获panic的传播就会停止程序从panic中恢复继续执行recover所在defer函数之后的代码并逐步返回到上层调用函数。但有一个铁律recover只有在defer函数中调用才有效。结合上一节的“动画”原因就非常直观了——因为只有defer函数是在栈展开过程中被执行的recover只有在这个阶段被调用才能“够得着”正在向上传播的panic。让我们把recover加进去。一个常见的模式是在顶层函数如main或 HTTP 处理器中使用defer和recover来防止整个程序或单个请求崩溃。package main import fmt func main() { fmt.Println(main start) // 在main的defer中尝试recover defer func() { if r : recover(); r ! nil { fmt.Printf(Recovered in main: %v\n, r) } }() level1() fmt.Println(main end) // 注意这行现在有机会执行了 } func level1() { fmt.Println(level1 start) defer fmt.Println(defer in level1) level2() fmt.Println(level1 end) } func level2() { fmt.Println(level2 start) defer fmt.Println(defer in level2) panic(panic in level2) fmt.Println(level2 end) }运行结果main start level1 start level2 start defer in level2 defer in level1 Recovered in main: panic in level2 main end动画过程解析panic在level2中发生。执行level2的defer(defer in level2)。panic传播到level1执行level1的defer(defer in level1)。panic传播到main。开始执行main的defer。在main的defer函数中recover()被调用。此时它成功捕获到了正在传播的panic并返回了panic的值”panic in level2″。关键点panic的传播在此刻被截停了。recover所在的defer函数正常执行完毕打印出恢复信息。由于panic已被处理程序不会崩溃。main函数从defer返回后继续执行defer之后的代码即fmt.Println(“main end”)。注意level1和level2中panic之后的代码level1 end,level2 end永远不会执行。因为panic导致它们所在的函数异常返回了执行权不会回到那里。recover只是在传播路径上“接住”了它但无法让已经“炸掉”的函数恢复执行。你可以把recover想象成在panic传播路径上设置的一个安全网。安全网defer中的recover只能接住从上面掉下来向上传播的panic而不能跳进已经炸毁的楼层已经发生panic的函数去救人。5. 实战中 recover 的边界与陷阱理解了基本原理我们来看几个实战中容易出错的地方。这些是判断你是否真懂了的关键。5.1 recover 必须在直接 defer 的函数中调用这是一个经典错误。recover必须在defer关键字后面那个函数里被直接调用。// 错误示例recover 不在 defer 的直接函数体内 func badRecover() { if r : recover(); r ! nil { fmt.Println(Recovered:, r) } } func main() { defer badRecover() // 这样是无效的 panic(test) } // 程序依然会崩溃。为什么因为defer badRecover()注册的是badRecover函数的执行。而badRecover函数是在panic发生后在栈展开时被调用的。此时badRecover函数内部的recover()调用是有效的。等一下这个例子看起来矛盾其实不矛盾这个例子里的recover是有效的。我举了一个不恰当的反例。让我们修正一下。真正的陷阱是recover必须是在panic发生的同一个 goroutine 的defer路径上被调用。更典型的无效用法是这样的func main() { defer func() { go func() { // 错误在新的 goroutine 中 recover 无效 if r : recover(); r ! nil { fmt.Println(这行不会执行) } }() }() panic(test) } // 程序会崩溃因为 recover 在另一个 goroutine 里。正确的写法就是我们在第4节用的一个匿名函数。defer func() { if r : recover(); r ! nil { // 处理恢复逻辑 } }()5.2 recover 只能捕获同一 goroutine 的 panicGo 的每个 goroutine 都有独立的执行栈和 panic/recover 机制。一个 goroutine 的recover无法捕获另一个 goroutine 中发生的panic。这是并发编程中常见的死因。package main import ( fmt time ) func safeGoRoutine() { defer func() { if r : recover(); r ! nil { fmt.Printf(Recovered in goroutine: %v\n, r) } }() panic(panic inside goroutine) } func main() { go safeGoRoutine() // 这个 goroutine 自己会 recover time.Sleep(100 * time.Millisecond) // 主 goroutine 没有 recover go func() { panic(panic in another goroutine) }() time.Sleep(1 * time.Second) // 等待看崩溃 fmt.Println(Main ends) // 可能打印不出来因为程序可能因第二个 goroutine panic 而崩溃 }你需要为每个可能panic的 goroutine 单独设立recover防线。这通常意味着在 goroutine 的入口函数最上层写defer recover。5.3 被 recover 后程序状态可能已损坏recover给了程序继续运行的机会但并不代表程序状态是健康的。panic往往发生在深层函数中可能已经破坏了数据的一致性例如只更新了一半的数据结构文件只写了一半。var globalCounter int func riskyOperation() { globalCounter panic(oops after increment) // globalCounter-- // 这行永远不会执行导致计数器状态错误 } func main() { defer func() { if r : recover(); r ! nil { fmt.Println(Recovered from:, r) fmt.Println(But globalCounter is now:, globalCounter) // 可能是错误的值 } }() riskyOperation() }经验法则recover之后通常应该记录详细的错误信息和栈跟踪可以用debug.Stack()。清理当前请求或任务的资源如关闭连接、回滚事务。让当前处理流程优雅失败而不是假装什么都没发生继续业务逻辑。例如在一个 HTTP 服务器中recover后应该返回一个 500 内部服务器错误响应而不是继续尝试生成响应体。5.4 如何获取被 recover 后的栈信息崩溃时打印的栈跟踪很有用。recover后我们仍然可以通过runtime/debug包来获取它。package main import ( fmt runtime/debug ) func deepFunc() { panic(deep panic) } func main() { defer func() { if r : recover(); r ! nil { fmt.Printf(Recovered: %v\n, r) fmt.Println(Stack trace at panic:) // 打印栈信息 debug.PrintStack() } }() deepFunc() }这会在recover后打印出完整的栈跟踪对于线上问题排查至关重要。6. 设计模式在哪里放置 recover 最有效知道了原理我们来谈谈实战中recover应该放在哪里。盲目地在每个函数开头都加defer recover是糟糕的设计它会掩盖错误让调试变得极其困难。6.1 边界处恢复Boundary Recovery这是最有效和推荐的模式。在模块、组件或并发单元的边界处设置recover。HTTP 服务器在每个 HTTP 请求处理器的入口或中间件设置recover确保一个请求的panic不会导致整个服务器进程崩溃。func myHTTPHandler(w http.ResponseWriter, r *http.Request) { defer func() { if r : recover(); r ! nil { log.Printf(Panic recovered: %v, r) http.Error(w, Internal Server Error, http.StatusInternalServerError) } }() // ... 实际的业务逻辑 ... }Goroutine 入口在启动 goroutine 的顶层函数里设置recover。go func() { defer func() { if r : recover(); r ! nil { log.Printf(Goroutine panic recovered: %v, r) // 可能还需要通知主循环此 goroutine 已异常退出 } }() doBackgroundTask() }()主函数 main在main函数中设置一个最终的recover可以捕获初始化阶段或其他未受保护的 goroutine 中漏网的panic至少能让你有机会记录日志、清理资源后再退出。func main() { defer func() { if r : recover(); r ! nil { log.Fatalf(Fatal panic in main: %v, r) } }() // ... 程序主逻辑 ... }6.2 避免在库代码中随意 recover作为一个库的作者你的函数被谁调用、在什么上下文中调用是未知的。除非你的库文档明确声明会在内部处理某些特定错误并转换为panic否则通常不应该在库的内部函数里使用recover。让panic自然地传播到调用方应用程序代码由调用方在边界处决定如何处理这样调用者才能获得完整的错误上下文。一个在库内部悄悄recover并只返回一个普通错误的函数会让调用者丢失“这里发生了严重异常”的关键信息。7. 总结把调用栈动画刻在脑子里最后我们回顾一下整个“动画”流程形成肌肉记忆触发当执行到panic(v)时当前函数的正常执行立即停止。展开开始Go 运行时开始逆序执行当前函数中已注册的defer函数。传播当前函数的defer执行完毕后panic会沿着调用栈向上“传播”到调用者函数。逐层展开在每个上层函数中同样是先停止正常执行逆序执行该函数的defer。救援检查在执行任何一个defer函数时如果其中调用了recover()recover会捕获到当前正在传播的panic值v并停止panic的进一步传播。恢复执行recover所在的defer函数正常执行完后程序从panic中恢复继续执行该defer所在函数中剩余的代码如果有的话然后该函数正常返回控制权继续向上层交还。无救援崩溃如果panic一直传播到最顶层的main函数且在其defer中仍未recover则程序崩溃打印panic值和完整的栈跟踪。记住这个画面你就能对 Go 程序的异常流控了如指掌。下次再看到panic输出你看到的将不再是一堆令人困惑的文件名和行号而是一幅清晰的、函数层层返回、defer依次执行的动态画卷。而recover就是你在画卷关键位置设置的一个“暂停键”。
