这是帖子的摘录；完整的帖子可以在这里找到：golang defer：从基础到陷阱。
defer 语句可能是我们开始学习 go 时首先发现非常有趣的事情之一，对吗？
但是它还有很多让很多人困惑的地方，并且有很多令人着迷的方面是我们在使用它时经常没有触及的。
例如，defer 语句实际上有 3 种类型（从 go 1.22 开始，尽管稍后可能会改变）：开放编码 defer、堆分配 defer 和堆栈分配。每一种都有不同的性能和不同的最佳使用场景，如果您想优化性能，了解这一点很有帮助。
在本次讨论中，我们将涵盖从基础知识到更高级用法的所有内容，我们甚至会深入研究一些内部细节。
立即学习“go语言免费学习笔记（深入）”；
什么是延期？
在我们深入研究之前，让我们快速了解一下 defer。
在 go 中，defer 是一个关键字，用于延迟函数的执行，直到周围的函数完成。
func main() {
defer fmt.println("hello")
fmt.println("world")
}
// output:
// world
// hello
在此代码片段中，defer 语句安排 fmt.println("hello") 在 main 函数的最后执行。因此，立即调用 fmt.println("world")，并首先打印“world”。之后，因为我们使用了 defer，所以在 main 完成之前的最后一步会打印“hello”。
这就像设置一个任务稍后运行，就在函数退出之前运行。这对于清理操作非常有用，例如关闭数据库连接、释放互斥体或关闭文件：
func dosomething() error {
f, err := os.open("phuong-secrets.txt")
if err != nil {
return err
}
defer f.close()
// ...
}
上面的代码是一个很好的例子来展示 defer 是如何工作的，但这也是一个不好的使用 defer 的方式。我们将在下一节中讨论这个问题。
“好吧，很好，但是为什么不把 f.close() 放在最后呢？”
这样做有几个很好的理由：
- 我们将关闭操作放在打开附近，这样更容易遵循逻辑并避免忘记关闭文件。我不想向下滚动函数来检查文件是否已关闭；它分散了我对主要逻辑的注意力。
- 即使发生panic（运行时错误），延迟函数也会在函数返回时被调用。
发生恐慌时，堆栈将被展开，并且延迟函数将按特定顺序执行，我们将在下一节中介绍。
延迟已堆积
当您在函数中使用多个 defer 语句时，它们会按“堆栈”顺序执行，这意味着最后一个延迟函数会先执行。
func main() {
defer fmt.println(1)
defer fmt.println(2)
defer fmt.println(3)
}
// output:
// 3
// 2
// 1
每次调用 defer 语句时，都会将该函数添加到当前 goroutine 链表的顶部，如下所示：
当函数返回时，它会遍历链表并按照上图所示的顺序执行每一个。
但是请记住，它不会执行 goroutine 链表中的所有 defer，它只运行返回函数中的 defer，因为我们的 defer 链表可能包含来自许多不同函数的许多 defer。
func b() {
defer fmt.println(1)
defer fmt.println(2)
a()
}
func a() {
defer fmt.println(3)
defer fmt.println(4)
}
因此，仅执行当前函数（或当前堆栈帧）中的延迟函数。
但是有一种典型情况，当前 goroutine 中的所有延迟函数都被跟踪并执行，那就是发生恐慌的时候。
延迟、恐慌和恢复
除了编译时错误之外，我们还有很多运行时错误：除以零（仅限整数）、越界、取消引用 nil 指针等等。这些错误会导致应用程序出现恐慌。
panic 是一种停止当前 goroutine 执行、展开堆栈并执行当前 goroutine 中的延迟函数的方法，从而导致我们的应用程序崩溃。
为了处理意外错误并防止应用程序崩溃，您可以在延迟函数中使用恢复函数来重新获得对恐慌 goroutine 的控制。
func main() {
defer func() {
if r := recover(); r != nil {
fmt.println("recovered:", r)
}
}()
panic("this is a panic")
}
// output:
// recovered: this is a panic
通常，人们会在恐慌中放入错误并使用recover(..)捕获该错误，但它可以是任何东西：字符串、整数等。
在上面的例子中，延迟函数内部是唯一可以使用recover的地方。让我再解释一下。
我们可以在这里列出一些错误。我在实际代码中至少见过三个这样的片段。
第一个是，直接使用recover作为延迟函数：
func main() {
defer recover()
panic("this is a panic")
}
上面的代码仍然会出现恐慌，这是 go 运行时的设计。
recover 函数旨在捕获恐慌，但必须在延迟函数中调用它才能正常工作。
在幕后，我们对恢复的调用实际上是runtime.gorecover，它检查恢复调用是否在正确的上下文中发生，特别是来自发生恐慌时处于活动状态的正确的延迟函数。
“这是否意味着我们不能在延迟函数内的函数中使用恢复，就像这样？”
func myrecover() {
if r := recover(); r != nil {
fmt.println("recovered:", r)
}
}
func main() {
defer func() {
myrecover()
// ...
}()
panic("this is a panic")
}
确切地说，上面的代码不会像你想象的那样工作。这是因为恢复不是直接从延迟函数调用，而是从嵌套函数调用。
现在，另一个错误是试图从不同的 goroutine 中捕获恐慌：
func main() {
defer func() {
if r := recover(); r != nil {
fmt.println("recovered:", r)
}
}()
go panic("this is a panic")
time.sleep(1 * time.second) // wait for the goroutine to finish
}
有道理吧？我们已经知道延迟链属于特定的 goroutine。如果一个 goroutine 可以干预另一个 goroutine 来处理恐慌，那就很困难了，因为每个 goroutine 都有自己的堆栈。
不幸的是，在这种情况下，如果我们不处理该 goroutine 中的恐慌，唯一的出路就是使应用程序崩溃。
延迟参数，包括立即评估接收者
我以前遇到过这个问题，旧数据被推送到分析系统，很难找出原因。
这就是我的意思：
func pushAnalytic(a int) {
fmt.Println(a)
}
func main() {
a := 10
defer pushAnalytic(a)
a = 20
}
你认为输出会是什么？是10个，不是20个。
那是因为当您使用 defer 语句时，它会立即获取值。这称为“按值捕获”。因此，当延迟被安排时，发送到pushanalytic的a的值被设置为10，即使a稍后发生变化。
有两种方法可以解决这个问题。
...
完整帖子可在此处查看：golang defer：从基础到陷阱。
