Go：函数、闭包、defer、panic、recover 应该怎么系统理解

发表于 2018-05-30 分类于 Go 本文字数： 5.5k 阅读时长 ≈ 20 分钟

围绕一个批量任务执行器，把 Go 里的函数值、闭包捕获、defer 的求值和执行时机、panic 与 recover 的边界、资源清理和工程判断一次讲清楚。

学 Go 到这里时，经常会同时遇到几种互相打架的说法：

Go 的函数可以像变量一样传来传去
闭包很方便，但线上 bug 也经常跟它有关
defer 非常适合做收尾，可一多又担心性能和执行顺序
panic 看起来很像异常，但 Go 又强调错误要显式返回
recover 能兜底，但代码里经常写了以后发现根本没接住

这些概念单独看都不难，真正难的是它们经常会在同一段真实代码里同时出现。

比如你在做一个批量任务执行器：

任务本身可以抽象成函数值
任务构造器经常会用闭包捕获配置
执行过程中要 defer 释放资源、记录耗时、更新状态
某个插件内部如果直接 panic，又不能把整个批次拖垮
你还得判断哪些地方该 panic，哪些地方应该老老实实返回 error

所以这一篇不按零碎语法点来讲，而是围绕一个实际场景，把这几件事放进同一条主线里讲清楚。

一、这篇文章要解决什么问题

读完这一篇，应该能独立回答下面这些问题：

Go 里的函数到底是不是“值”，能不能赋值、传参、返回
闭包到底捕获了什么，为什么循环里最容易踩坑
defer 参数什么时候求值，真正的函数调用又什么时候执行
panic 和 error 的职责边界到底是什么
recover 必须写在什么位置才有效
资源清理、日志补录、状态回写这类收尾逻辑应该怎么组织
在工程里，什么时候该用这些能力，什么时候反而该克制

如果这几件事能真正独立说清楚，后面你再写中间件、HTTP 服务、worker、插件系统，代码会稳很多。

二、先看这篇文章里的实际场景

假设现在要写一个最小的批量任务执行器，它要做这些事：

接收一批任务
逐个执行
记录任务开始和结束时间
无论成功失败，都要把资源释放掉
如果某个任务内部 panic，要把它转成失败结果，而不是把整个进程直接打死

先定义最小模型：

type TaskFunc func(*TaskContext) error

type TaskContext struct {
	Name    string
	Env     string
	Logs    []string
	Closed  bool
	Counter map[string]int
}

type TaskResult struct {
	Name      string
	Status    string
	Err       error
	PanicText string
}

这个场景里：

TaskFunc 让函数本身成为可传递的执行单元
闭包可以提前把环境、阈值、前缀配置好
defer 负责收尾和资源释放
panic/recover 负责处理“不应该继续执行”的异常路径

后面所有概念都围绕这条线展开。

三、先给一个最小可运行示例

先看一个最小版本，别急着一次把概念讲满。

package main

import (
	"fmt"
)

type TaskContext struct {
	Name string
	Logs []string
}

type TaskFunc func(*TaskContext) error

func runTask(name string, task TaskFunc) {
	ctx := &TaskContext{Name: name}

	defer func() {
		fmt.Println("final logs:", ctx.Logs)
	}()

	err := task(ctx)
	if err != nil {
		fmt.Println("task failed:", err)
		return
	}

	fmt.Println("task success")
}

func main() {
	task := func(ctx *TaskContext) error {
		ctx.Logs = append(ctx.Logs, "check login api")
		return nil
	}

	runTask("smoke-login", task)
}

这段代码已经把几件事带出来了：

函数可以赋值给变量 task
函数可以作为参数传入 runTask
defer 可以在函数退出前统一收尾
任务逻辑和执行框架已经分开

后面要做的，就是把这几个点真正讲透，而不是停留在“知道能这么写”。

四、函数在 Go 里到底是什么

Go 里的函数不是只能“定义完直接调用”的语法糖，它本身就是一种值。

先看最简单的写法：

package main

import "fmt"

func add(a, b int) int {
	return a + b
}

func main() {
	f := add
	fmt.Println(f(2, 3))
}

输出：

这里可以先得出三个结论：

函数可以赋值给变量
变量里放的是“可调用的函数值”
函数值的类型由参数列表和返回值共同决定

所以你完全可以把函数当成一种“行为对象”：

传给调度器
存进切片
作为返回值交给外层

这也是很多 Go 工程里中间件、选项模式、回调函数、重试策略的基础。

五、函数类型和函数值怎么用才不会乱

真实项目里，不建议到处直接写很长的匿名函数签名。
更稳的做法通常是先把函数类型命名出来。

例如：

1
2
3

type TaskFunc func(*TaskContext) error

type CleanupFunc func(*TaskContext)

这样做有几个好处：

代码可读性更强
看到签名就知道职责
更容易组合成统一的执行框架

例如可以很自然地把任务列表放进切片：

tasks := []TaskFunc{
	func(ctx *TaskContext) error {
		ctx.Logs = append(ctx.Logs, "ping dependency")
		return nil
	},
	func(ctx *TaskContext) error {
		ctx.Logs = append(ctx.Logs, "check config")
		return nil
	},
}

也可以把函数作为返回值：

func buildTagAppender(tag string) TaskFunc {
	return func(ctx *TaskContext) error {
		ctx.Logs = append(ctx.Logs, "tag="+tag)
		return nil
	}
}

这其实已经进入闭包的地带了，因为返回的匿名函数用到了外层的 tag。

六、闭包到底捕获了什么

闭包最容易被讲成一句很虚的话：“函数和它引用的外部环境组成闭包。”

这句话没错，但对写代码帮助不大。
更实用的理解方式是：

匿名函数内部如果用到了外层作用域的变量
这个变量在函数返回后仍然可能继续被使用
那么这个函数值就和那份外层变量形成了绑定

先看例子：

package main

import "fmt"

func buildCounter(prefix string) func() string {
	count := 0

	return func() string {
		count++
		return fmt.Sprintf("%s-%d", prefix, count)
	}
}

func main() {
	next := buildCounter("job")

	fmt.Println(next())
	fmt.Println(next())
	fmt.Println(next())
}

输出：

1
2
3

job-1
job-2
job-3

这里匿名函数捕获了两个外层变量：

prefix
count

所以你每次调用 next()，都不是在执行一段“完全无状态”的代码，而是在操作那份已经被保留下来的环境。

这也是闭包最有价值的地方：

它能把配置提前固化
它能把状态局部封装起来
它能避免到处再定义一个临时 struct 只为传两三个字段

但它最危险的地方也在这里：状态被保留下来了，所以副作用也会被保留下来。

七、闭包最容易踩坑的地方：循环变量和可变外部状态

一讲闭包，最容易先想到“循环变量捕获”这个经典坑。
但这里先要加一个版本前提：

在旧版本 Go 里，这确实是高频坑
从 Go 1.22 开始，for 循环变量语义做了调整，每轮迭代会创建新的变量
所以如果模块语言版本已经是 go 1.22 或更新，很多教程里最经典的那种 for _, v := range list 闭包示例，已经不再按老方式出错

不过这不等于闭包相关的问题消失了。
真正更底层的风险始终是：你捕获的是会继续变化的外部状态。

先看一个今天依然会出问题的写法：

package main

import "fmt"

func main() {
	names := []string{"login", "order", "refund"}
	var tasks []func()
	current := ""

	for _, name := range names {
		current = name
		tasks = append(tasks, func() {
			fmt.Println(current)
		})
	}

	for _, task := range tasks {
		task()
	}
}

如果你对闭包捕获理解不稳，这里很容易以为输出是：

1
2
3

login
order
refund

但实际输出会是：

1
2
3

refund
refund
refund

原因很直接：

current 是循环外的同一个变量
每轮都在改它
所有闭包最终读到的，都是循环结束后的最后一个值

更稳的写法是每轮创建一个新的局部变量：

for _, name := range names {
	currentName := name
	tasks = append(tasks, func() {
		fmt.Println(currentName)
	})
}

这类坑在真实项目里特别常见，因为你经常会：

在循环里注册路由
在循环里启动 goroutine
在循环里构造校验器、回调函数、重试函数
在闭包里直接引用循环外的配置对象、切片、map、指针

一旦捕获错了，最后所有函数都可能读到同一个变量状态。

如果你的项目还停留在 go 1.21 或更早版本，那么经典的循环变量闭包坑依然可能出现；
如果项目已经在 go 1.22+，那你更应该把注意力放在“是否捕获了持续变化的外部状态”上。

如果你想记得更牢，可以先记一句更工程化的话：

闭包默认捕获的是变量和环境，不是自动帮你冻结出来的一份快照。

八、`defer` 到底什么时候求值，什么时候执行

defer 的真正坑点，不在“它会延迟执行”，而在：

它的参数会在 defer 语句出现时求值
真正的函数调用会在外层函数返回前执行

先看最经典的例子：

package main

import "fmt"

func main() {
	status := "running"

	defer fmt.Println("defer 1:", status)

	status = "done"

	fmt.Println("current:", status)
}

输出：

1 2	current: done defer 1: running

为什么 defer 打出来的是 running？

因为：

执行到 defer fmt.Println("defer 1:", status) 这一行时
fmt.Println 的参数已经先算出来了
当时 status 的值就是 running
只是这次函数调用被推迟到 main 返回前再执行

再看另一种写法：

1
2
3

defer func() {
	fmt.Println("defer 2:", status)
}()

如果中间再改：

1	status = "done"

那么最后输出会是：

1	defer 2: done

因为这里延迟的不只是调用时机，闭包里读变量的动作也被延迟到了真正执行那一刻。

所以关于 defer，至少要把下面两件事分开：

defer f(x)：x 先求值，再延迟调用
defer func() { use(x) }()：对 x 的读取发生在真正执行时

这个差异在记录耗时、补日志、回写状态时非常关键。

九、`defer` 最适合解决什么问题

知道 defer 好用以后，接下来更关键的是分清它到底该优先用在哪些地方。

最典型的场景有四类：

释放资源
解锁
补结束日志
统一更新状态和指标

先看资源释放：

func run() error {
	file, err := os.Open("task.log")
	if err != nil {
		return err
	}
	defer file.Close()

	// 后面出现多个 return 也不用担心漏关文件
	return nil
}

再看锁：

1 2	mu.Lock() defer mu.Unlock()

再看耗时统计：

func runTask(name string) {
	start := time.Now()

	defer func() {
		fmt.Println(name, "cost:", time.Since(start))
	}()

	// do work
}

这里有个很实用的判断标准：

只要一段逻辑“进入后必然需要对称地收尾”
defer 往往就比手工在每个 return 前写一遍更稳

但这并不等于“所有清理都丢给 defer 就行”。
如果一个循环执行量很大，而且每次循环里都 defer，你就要先意识到清理动作会累积到函数退出时才统一执行，这可能根本不是你想要的行为。

十、`panic` 到底是什么，不要把它当普通错误返回

panic 很容易被用成“高级版 error”。
这是很危险的。

panic 更接近一种“程序已经进入不正常状态，当前控制流无法继续按常规处理”的信号。

例如：

1	panic("task config is corrupted")

和普通 error 的差别在于：

error 是显式返回，调用方决定怎么处理
panic 会中断当前函数的正常流程，开始沿调用栈向上展开
在展开过程中，当前栈帧里注册过的 defer 会按后进先出的顺序执行

先看一个最小例子：

package main

import "fmt"

func main() {
	defer fmt.Println("cleanup")
	panic("boom")
}

输出会先看到：

cleanup

然后程序崩掉。

这说明 panic 不是“什么都不执行直接退出”，它仍然会触发栈展开和 defer 执行。

工程里更实用的判断是：

用户输入错误、网络错误、文件不存在、依赖超时，这些通常都应该返回 error
程序内部不变量被破坏、绝不应该发生的状态出现、初始化阶段发现致命配置错误，这些才更接近 panic 的使用边界

十一、`recover` 到底能接住什么

recover 也很容易被误用。

它不是“在任何地方调用都能把 panic 吃掉”的魔法函数。
想让它生效，至少要满足两个条件：

它必须在 defer 里调用
这个 defer 必须处在正在发生 panic 的那条 goroutine 的调用栈上

先看正确写法：

func safeRun(task func()) (panicText string) {
	defer func() {
		if r := recover(); r != nil {
			panicText = fmt.Sprint(r)
		}
	}()

	task()
	return ""
}

再看一种经常无效的写法：

func wrong() {
	if r := recover(); r != nil {
		fmt.Println("never here")
	}
}

这个 recover() 没放在 defer 里，正常情况下不会替你兜住 panic。

还有一个高频误区是：
主 goroutine 里写了 recover，就以为所有 goroutine 的 panic 都能被它接住。

这也不对。
哪个 goroutine 可能 panic，就应该在哪个 goroutine 的入口附近自己做恢复保护。

十二、把这些能力放进一个真实的小项目：批量任务执行器

下面把函数值、闭包、defer、panic/recover 放到同一个小项目里。

这个执行器要支持：

用函数表示任务
用闭包构造不同环境的任务
统一记录日志
无论成功失败都释放资源
单个任务 panic 后转成失败结果，不拖垮整批执行

package runner

import (
	"fmt"
	"strings"
	"time"
)

type TaskFunc func(*TaskContext) error

type TaskContext struct {
	Name    string
	Env     string
	Logs    []string
	Closed  bool
	Counter map[string]int
}

type TaskResult struct {
	Name      string
	Status    string
	Err       error
	PanicText string
	Duration  time.Duration
}

func (c *TaskContext) Close() {
	c.Closed = true
	c.Logs = append(c.Logs, "resource closed")
}

func BuildHealthCheckTask(env string, services []string) TaskFunc {
	serviceList := append([]string(nil), services...)

	return func(ctx *TaskContext) error {
		ctx.Logs = append(ctx.Logs, "env="+env)

		for _, service := range serviceList {
			ctx.Logs = append(ctx.Logs, "check "+service)
			if strings.TrimSpace(service) == "" {
				return fmt.Errorf("empty service name")
			}
		}

		ctx.Counter["checked"] += len(serviceList)
		return nil
	}
}

func BuildPanicTask(reason string) TaskFunc {
	return func(ctx *TaskContext) error {
		ctx.Logs = append(ctx.Logs, "about to panic")
		panic(reason)
	}
}

func RunTask(name, env string, task TaskFunc) (result TaskResult) {
	ctx := &TaskContext{
		Name:    name,
		Env:     env,
		Counter: map[string]int{},
	}
	start := time.Now()

	result.Name = name
	result.Status = "success"

	defer func() {
		result.Duration = time.Since(start)
		ctx.Close()
	}()

	defer func() {
		if r := recover(); r != nil {
			result.Status = "panic"
			result.PanicText = fmt.Sprint(r)
			result.Err = fmt.Errorf("task panic: %v", r)
			ctx.Logs = append(ctx.Logs, "panic recovered")
		}
	}()

	err := task(ctx)
	if err != nil {
		result.Status = "failed"
		result.Err = err
		return
	}

	ctx.Logs = append(ctx.Logs, "task done")
	return
}

这段代码里有几件事值得单独看：

TaskFunc 让任务成为函数值
BuildHealthCheckTask 返回闭包，把 env 和 services 固化进任务
append([]string(nil), services...) 是为了避免调用方后续修改原切片，把任务内部配置串掉
第一个 defer 负责统一收尾
第二个 defer 负责恢复 panic
panic 被转换成 TaskResult 里的失败信息，批次还能继续跑

这已经是一个很像实际项目骨架的最小版本了。

十三、这个小项目里最容易写错的地方

1. 忘记复制闭包依赖的切片

如果你这么写：

func BuildTask(services []string) TaskFunc {
	return func(ctx *TaskContext) error {
		for _, service := range services {
			ctx.Logs = append(ctx.Logs, service)
		}
		return nil
	}
}

然后外层又改了：

1	services[0] = "mutated-service"

那么任务运行时读到的就是改过后的内容。
如果你的语义是“构造任务时冻结配置”，就应该主动复制一份。

2. 以为 `defer` 参数会读取最新值

错误示例：

func mark() {
	status := "init"
	defer fmt.Println("status:", status)
	status = "done"
}

这里很容易以为最后会打印 done，其实打印的是 init。

3. 在循环里用 `defer` 释放大量资源

错误示例：

for _, path := range paths {
	file, _ := os.Open(path)
	defer file.Close()
}

这会导致所有文件都要等到外层函数结束才关闭。
如果循环很大，很容易把文件句柄占满。

更稳的写法是把单次处理封进一个小函数，让 defer 在那一层及时生效：

for _, path := range paths {
	if err := func() error {
		file, err := os.Open(path)
		if err != nil {
			return err
		}
		defer file.Close()

		return nil
	}(); err != nil {
		return err
	}
}

4. 以为 `recover` 可以跨 goroutine 生效

错误示例：

func main() {
	defer func() {
		if r := recover(); r != nil {
			fmt.Println("recovered:", r)
		}
	}()

	go func() {
		panic("worker boom")
	}()
}

这里主 goroutine 的 recover 不会替子 goroutine 兜住。
子 goroutine 自己的入口必须加保护。

十四、给这段逻辑补最小测试

这类文章如果只讲概念，很容易留下“好像懂了”的错觉。
更稳的方法是直接补最小测试，把行为固定下来。

可以写一个 runner_test.go：

package runner

import (
	"errors"
	"testing"
)

func TestRunTaskSuccess(t *testing.T) {
	task := BuildHealthCheckTask("test", []string{"login", "order"})

	result := RunTask("smoke", "test", task)

	if result.Status != "success" {
		t.Fatalf("want success, got %s", result.Status)
	}
	if result.Err != nil {
		t.Fatalf("unexpected err: %v", result.Err)
	}
}

func TestRunTaskFailed(t *testing.T) {
	task := func(ctx *TaskContext) error {
		return errors.New("dependency timeout")
	}

	result := RunTask("smoke", "test", task)

	if result.Status != "failed" {
		t.Fatalf("want failed, got %s", result.Status)
	}
	if result.Err == nil {
		t.Fatal("want non-nil err")
	}
}

func TestRunTaskPanicRecovered(t *testing.T) {
	task := BuildPanicTask("bad plugin state")

	result := RunTask("smoke", "test", task)

	if result.Status != "panic" {
		t.Fatalf("want panic, got %s", result.Status)
	}
	if result.PanicText == "" {
		t.Fatal("want panic text")
	}
	if result.Err == nil {
		t.Fatal("want converted err")
	}
}

func TestBuildHealthCheckTaskCopiesServices(t *testing.T) {
	services := []string{"login", "order"}
	task := BuildHealthCheckTask("test", services)
	services[0] = "mutated"

	ctx := &TaskContext{
		Name:    "smoke",
		Env:     "test",
		Counter: map[string]int{},
	}

	if err := task(ctx); err != nil {
		t.Fatalf("unexpected err: %v", err)
	}

	if ctx.Logs[1] != "check login" {
		t.Fatalf("closure should keep copied config, got %v", ctx.Logs)
	}
}

这几组测试分别固定了四件事：

成功路径
error 路径
panic/recover 路径
闭包是否错误地共享了外部切片

十五、怎么验证这段代码

如果你把示例单独落成一个小目录，至少要做下面几步验证。

1. 跑最小测试

1	go test ./...

2. 单独验证 `panic` 转换是否符合预期

你可以临时加一个简单入口：

func main() {
	result := RunTask("panic-task", "test", BuildPanicTask("broken state"))
	fmt.Printf("%+v\n", result)
}

你应该看到：

程序没有整段崩掉
Status 是 panic
PanicText 有值
Err 也被补出来了

3. 单独验证 `defer` 的参数求值时机

func main() {
	status := "running"

	defer fmt.Println("value:", status)
	defer func() {
		fmt.Println("closure:", status)
	}()

	status = "done"
}

预期输出是：

1 2	closure: done value: running

这个例子非常适合用来固定你对 defer 的理解。

十六、线上排障时怎么判断自己踩的是哪一类坑

这些概念真正麻烦的地方是：线上现象看起来很像，根因却完全不同。

可以按下面这条线去拆。

1. 日志里为什么配置值不对

先查是不是闭包捕获了会变化的外部变量：

是否在循环里构造了匿名函数
是否直接捕获了外部切片、map、指针
任务构造后，外层配置对象有没有继续被修改

2. 为什么 `defer` 打印的不是最新状态

先查你写的是：

defer fmt.Println(x)
还是 defer func() { fmt.Println(x) }()

这两种语义完全不同。

3. 为什么资源没有及时释放

先查：

defer 是不是写在大循环里
函数是不是一直没退出
是否把“每轮循环结束时 defer 就会执行”理解成默认行为

4. 为什么进程还是崩了

先查：

recover 是否真的写在 defer 里
recover 和 panic 是否在同一个 goroutine 的栈上
panic 之后是否又再次 panic

5. 为什么结果对象状态怪异

先查命名返回值和 defer 是否同时修改了结果：

func run() (err error) {
	defer func() {
		if err != nil {
			err = fmt.Errorf("wrapped: %w", err)
		}
	}()

	err = doSomething()
	return
}

这种写法本身不是错，但如果团队对命名返回值不熟，很容易把状态改乱。

十七、工程边界：什么时候该用，什么时候不要滥用

到这里，最重要的已经不是“会不会写”，而是什么时候该写。

1. 函数值和闭包适合什么场景

适合：

中间件链
重试策略
任务装配器
配置固化后的执行器

不适合：

隐式共享太多可变状态
闭包体过长，已经比单独定义类型和方法更难读

2. `defer` 适合什么场景

适合：

文件、连接、锁等成对资源管理
收尾日志
统一状态更新

不适合：

超大循环里无脑堆很多 defer
需要立刻释放资源却把 defer 理解成“当前块结束就执行”

3. `panic` 适合什么场景

适合：

绝不应该发生的程序内部错误
初始化阶段发现核心配置损坏
明确要快速中止且不能继续运行的致命状态

不适合：

普通业务校验失败
依赖调用超时
文件不存在
用户参数错误

这些本质上都应该返回 error。

4. `recover` 适合什么场景

适合：

框架边界
goroutine 入口保护
插件执行沙箱
单个请求/任务的最外层保护

不适合：

到处乱包一层，把真实程序错误全部吞掉

如果你用了 recover，至少要保证：

日志里能看到 panic 内容和堆栈
监控里能统计出来
不会把本该暴露的问题悄悄隐藏掉

十八、一个实际练习

你可以基于这一篇的执行器，自己补一个 BuildRetryTask(maxRetry int, action TaskFunc) TaskFunc。

要求：

闭包里固化 maxRetry
每次失败都写一条日志
成功就提前返回
如果 maxRetry <= 0，返回明确错误
如果内部任务发生 panic，不要在重试层吞掉，交给 RunTask 的最外层恢复逻辑处理

做完这个练习后，会同时用到：

函数值作为参数
闭包捕获配置
显式错误返回
最外层 panic/recover 边界控制

这比单独背概念有效得多。

十九、结语

这一篇真正想建立的，不是几个零散语法点，而是一套更稳的判断方式：

函数在 Go 里是值，可以被组织成执行单元
闭包很强，但它捕获的是变量和环境，不是“自动帮你冻结状态”
defer 最核心的不是“延迟”两个字，而是求值时机和执行时机要分开理解
panic 不是普通错误返回的替代品
recover 不是万能保险丝，它只应该出现在明确的框架边界

如果这套判断已经稳了，后面再学方法集、接口、goroutine、channel、中间件和并发控制时，你就不会老把“语言机制”和“工程边界”混在一起。

一、这篇文章要解决什么问题

二、先看这篇文章里的实际场景

三、先给一个最小可运行示例

四、函数在 Go 里到底是什么

五、函数类型和函数值怎么用才不会乱

六、闭包到底捕获了什么

七、闭包最容易踩坑的地方：循环变量和可变外部状态

八、defer 到底什么时候求值，什么时候执行

九、defer 最适合解决什么问题

十、panic 到底是什么，不要把它当普通错误返回

十一、recover 到底能接住什么

十二、把这些能力放进一个真实的小项目：批量任务执行器

十三、这个小项目里最容易写错的地方

1. 忘记复制闭包依赖的切片

2. 以为 defer 参数会读取最新值

3. 在循环里用 defer 释放大量资源

4. 以为 recover 可以跨 goroutine 生效

十四、给这段逻辑补最小测试

十五、怎么验证这段代码

1. 跑最小测试

2. 单独验证 panic 转换是否符合预期

3. 单独验证 defer 的参数求值时机

十六、线上排障时怎么判断自己踩的是哪一类坑

1. 日志里为什么配置值不对

2. 为什么 defer 打印的不是最新状态

3. 为什么资源没有及时释放

4. 为什么进程还是崩了

5. 为什么结果对象状态怪异

十七、工程边界：什么时候该用，什么时候不要滥用

1. 函数值和闭包适合什么场景

2. defer 适合什么场景

3. panic 适合什么场景

4. recover 适合什么场景

十八、一个实际练习

十九、结语

八、`defer` 到底什么时候求值，什么时候执行

九、`defer` 最适合解决什么问题

十、`panic` 到底是什么，不要把它当普通错误返回

十一、`recover` 到底能接住什么

2. 以为 `defer` 参数会读取最新值

3. 在循环里用 `defer` 释放大量资源

4. 以为 `recover` 可以跨 goroutine 生效

2. 单独验证 `panic` 转换是否符合预期

3. 单独验证 `defer` 的参数求值时机

2. 为什么 `defer` 打印的不是最新状态

2. `defer` 适合什么场景

3. `panic` 适合什么场景

4. `recover` 适合什么场景