defer、panic与recover

defer是一条语句，它注册一个 延迟调用（deferred call） 。当前函数无论正常返回、执行到函数体末尾，还是因panic退出，已注册的调用都会在函数真正退出前运行。它把“取得资源”和“安排释放”放在一起，减少早返回路径漏掉文件关闭、解锁或状态复原的机会。

panic和recover是预声明函数，不是错误返回值的替代语法。panic表示当前控制流不能继续，例如运行时检测到切片越界，或程序发现内部不变量已经被破坏。普通失败仍应返回error：文件不存在、请求无效或远端超时，都属于调用者可能处理的结果。

发生panic后，Go会开始 panic展开（panic unwinding） 。运行时先执行当前函数的延迟调用，再沿同一个goroutine的调用栈逐层执行调用者的延迟调用。若一直没有恢复，程序会报告panic值和栈信息并终止。

recover让代码在一个刻意设置的 恢复边界（recovery boundary） 把panic转成受控结果。它适合隔离任务、保护服务器请求入口，或把包内部已知的panic转成公开的error。它不等同于其他语言中可在任意位置使用的catch，也不会从触发panic的语句之后继续执行。

执行defer f(x)时，Go会立即求出函数值f和实参x，并为这一次执行保存它们。实际调用要等当前函数退出。若延迟的是函数字面量，函数体运行时才读取它捕获的变量，因此“参数快照”和“闭包稍后读取”可能得到不同结果。

函数值与方法接收者

立即求值也适用于函数值和方法接收者。若变量cleanup在注册后指向另一个函数，已注册的调用仍使用原函数值；defer object.Close()也会在注册时确定接收者object。这让“释放刚取得的那个对象”保持稳定，不受变量后来重新赋值影响。

求值不等于调用。若延迟调用保存的函数值为nil，注册时不会panic；当前函数退出并尝试调用它时才会panic。任何实参求值本身产生的副作用或panic则发生在执行defer语句的当下。

同一函数内的延迟调用按注册顺序的逆序运行，也就是后进先出。正常return会先给结果参数赋值，再执行延迟调用，最后把结果交给调用者。因此，延迟闭包可以修改命名结果；这种能力应局限在短小、明确的收尾逻辑中。

panic会停止当前函数的普通语句，但不会跳过它的延迟调用。展开到某个函数G时，如果G直接延迟的函数调用了recover，recover会取得panic值并停止展开。G随后返回给自己的调用者；已经丢弃的中间栈帧不会恢复。

下面的流程同时覆盖正常返回和panic路径。恢复发生在延迟调用阶段，而不是触发panic的位置。

recover只有两个关键前提：调用它的函数必须正在作为延迟调用执行，而且panic必须来自同一个goroutine。普通函数调用中的recover()返回nil；父goroutine的延迟函数也看不到子goroutine的panic。边界必须安装在可能发生panic的那条执行栈上。

四种退出方式

几个看似相近的退出API对延迟调用和恢复有不同语义。区分它们能解释为什么某些清理代码根本没有机会运行。

return和panic是普通Go代码中最常见的两条退出路径。Goexit主要由运行时和测试基础设施使用，os.Exit则属于进程控制；把后二者当成普通函数返回会得到错误的清理假设。

panic值可以是任意类型，但边界需要能稳定记录和分类它。应用代码通常使用实现error的内部类型，并在确实允许转换的API边界保留其错误链。不要用易变的字符串前缀区分哪些panic可以恢复。

求值时机与后进先出

这个例子把直接传参的延迟调用与捕获变量的延迟闭包放在一起。输出区分了注册时求值和退出时读取。

fmt.Println的实参在第一条defer执行时已经保存，所以最后仍打印draft。闭包没有参数快照，它退出时读取label，看到的是final。闭包后注册，所以先运行。

实际代码中，如果清理需要资源句柄本身，直接把句柄作为接收者或参数通常更容易判断。只有当收尾逻辑确实需要退出时的状态，才让延迟闭包读取会变化的变量。

保留关闭错误

写入成功不代表数据已经成功刷新或关闭。下面的saveReport用命名结果让延迟函数合并写入错误与关闭错误，避免后一个错误覆盖前一个错误。

package main

import (
	"errors"
	"fmt"
	"io"
)

type reportSink struct {
	writeErr error
	closeErr error
}

func (s *reportSink) Write(p []byte) (int, error) {
	if s.writeErr != nil {
		return 0, s.writeErr
	}
	return len(p), nil
}

func (s *reportSink) Close() error { return s.closeErr }

func saveReport(sink io.WriteCloser) (err error) {
	defer func() {
		err = errors.Join(err, sink.Close())
	}()

	if _, err = sink.Write([]byte("weekly totals\n")); err != nil {
		return fmt.Errorf("write report: %w", err)
	}
	return nil
}

func main() {
	closeOnly := &reportSink{closeErr: errors.New("flush failed")}
	both := &reportSink{
		writeErr: errors.New("disk full"),
		closeErr: errors.New("flush failed"),
	}

	fmt.Printf("close only: %v\n", saveReport(closeOnly))
	fmt.Printf("both:\n%v\n", saveReport(both))
}

close only: flush failed
both:
write report: disk full
flush failed

errors.Join会忽略nil，因此关闭成功时不会制造错误。如果写入和关闭都失败，返回的错误同时包装两者，调用者可用errors.Is或errors.As检查任意一条错误链。这里的模拟sink只为让两条路径稳定复现。

命名结果会增加隐式状态，所以延迟函数应保持短小。若API明确规定关闭错误无意义，例如只读文件在读取结束后的关闭，简单的defer file.Close()可能已经足够；写入器和事务则需要检查各自的提交或关闭契约。

展开并恢复

下一段代码展示panic如何先触发各层清理，再到达恢复函数。恢复之后，run返回到main，不会重新执行loadIndex()后面的语句。

package main

import "fmt"

func loadIndex() {
	defer fmt.Println("loadIndex cleanup")
	panic("invalid index")
}

func run() {
	defer func() {
		if value := recover(); value != nil {
			fmt.Println("recovered:", value)
		}
	}()
	defer fmt.Println("run cleanup")

	loadIndex()
	fmt.Println("unreachable")
}

func main() {
	fmt.Println("start")
	run()
	fmt.Println("continued")
}

start
loadIndex cleanup
run cleanup
recovered: invalid index
continued

恢复函数在run中最先注册，因此在run cleanup之后才运行。它直接调用recover，取得字符串panic值。若删除这一个延迟函数，展开会继续越过main，程序最终终止。

示例为了展示机制而打印panic值。生产边界通常还要记录runtime/debug.Stack()，关联任务或请求标识，并决定当前状态能否安全继续；若答案是否定的，就不应恢复。

保护goroutine入口

一个goroutine不能恢复另一个goroutine的panic。要隔离独立任务，恢复函数必须放在新goroutine的入口附近，并通过明确的结果通道把失败交还给所有者。

package main

import "fmt"

type result struct {
	name string
	err  error
}

func guarded(name string, job func(), out chan<- result) {
	var err error
	defer func() {
		if value := recover(); value != nil {
			err = fmt.Errorf("panic: %v", value)
		}
		out <- result{name: name, err: err}
	}()

	job()
}

func main() {
	results := make(chan result, 2)
	go guarded("email", func() {}, results)
	go guarded("index", func() { panic("negative shard") }, results)

	byName := make(map[string]error)
	for range 2 {
		outcome := <-results
		byName[outcome.name] = outcome.err
	}

	fmt.Printf("email: %v\n", byName["email"])
	fmt.Printf("index: %v\n", byName["index"])
}

email: <nil>
index: panic: negative shard

两个goroutine的完成顺序不确定，所以示例先按名称保存结果，再按固定顺序打印。缓冲通道也让延迟函数发送结果时不依赖main已经开始接收。真实任务系统还需要取消、容量限制和栈记录，这些职责不能靠recover自动获得。

这里捕获所有panic是任务隔离器的既定契约，不适合包住任意业务函数。如果panic表示共享状态已经损坏，仅把它改写成error会让进程带着未知状态继续运行；边界必须明确哪些失败允许隔离。

修复： 把一次迭代提取成函数，并在该函数内注册关闭。这样每次调用结束就释放资源。不要为了避开defer而复制多条手工清理路径，那会重新引入早返回泄漏。

修复： 底层函数返回错误，让拥有进程退出策略的最外层决定如何记录和返回退出码。若main需要执行自己的延迟清理，就让它正常返回；在main中调用os.Exit同样会跳过这些清理。

修复： 只在任务、请求或包API的明确边界恢复，并记录原始panic值与栈。包内部若用私有panic类型简化递归展开，只转换该已知类型；遇到未知值时重新panic。

修复： 在可能panic的同一个goroutine中直接defer func() { value := recover(); ... }()。创建goroutine的封装器应同时负责汇报结果，避免恢复后悄悄丢失任务。

修复： 阅读具体接口契约。关闭失败有意义时，用命名结果或显式收尾合并错误，并保留原始错误链。对锁的Unlock等不返回错误的操作，直接延迟调用即可。

修复： 在注册前验证可选回调，或只在它非nil时注册。不要依赖后面的赋值来“补上”函数，因为defer已经保存了注册时的函数值。

• Go语言规范：Defer statements
• Go语言规范：Handling panics
• Go 1.27发布说明
• errors.Join文档
• runtime.Goexit文档
• os.Exit文档