Go init 与 defer：初始化顺序、资源生命周期和 panic 边界

面向有 Java 经验的开发者，基于 Go 1.26。

init 和 defer 都与“什么时候执行”有关，但它们解决的是完全不同的问题：

init 管包加载阶段，在 main 之前建立包级状态；
defer 管一次函数调用的退出阶段，保证清理、解锁、观测或错误合并；
panic/recover 借助 defer 展开调用栈，用于隔离不可继续的异常边界。

语法本身不长，麻烦往往藏在执行时机里：初始化顺序取决于包图，空白导入会带来不易察觉的副作用；defer 的参数在登记时求值，调用却按后进先出执行；os.Exit 会绕过所有 defer；关闭资源时产生的错误，也可能是这次调用真正需要返回的错误。理解这些行为，不能只背语法，还要把执行模型和资源边界放在一起看。

1. 先建立时间线

先沿着一个普通可执行程序的时间线走一遍：

text

运行时准备
  ↓
初始化所有依赖包（依赖更深的先完成）
  ↓
初始化 main 包的包级变量
  ↓
执行 main 包的 init
  ↓
调用 main.main
  ↓
每次函数返回或 panic 展栈时，执行该调用已登记的 defer
  ↓
main.main 正常返回，进程退出

这条时间线上有三个关键点：

包级初始化是单线程、按依赖进行的；
defer 属于某一次函数调用，不属于词法块；
panic 展开当前 goroutine 的调用栈，recover 只能在特定 deferred call 中拦截。

init 不是构造器，defer 也不是通用的“作用域结束钩子”。拿 Java 的 static initializer 和 try-with-resources 类比可以帮助入门，但最终应以 Go 的函数调用和包依赖模型为准。

2. 包初始化的完整顺序

2.1 依赖包先于当前包

假设：

text

main → service → repository → database
             ↘ model

初始化 service 之前，repository、model 及它们的依赖必须完成。每个包只初始化一次。即使多个包都导入 model，也不会重复初始化。

程序会根据依赖关系，选择所有依赖均已完成、但自身尚未初始化的包。结果就是依赖先于使用者。至于两个“同层兄弟包”谁先执行，不应成为它们通信的前提；这类关系要通过显式依赖，或在 main 中完成装配。

2.2 一个包内部

包内顺序分两阶段：

按依赖关系初始化包级变量；
按出现顺序调用各个 init 函数。

package config

var raw = loadRaw()
var parsed = parse(raw)

func init() {
	validate(parsed)
}

raw 和 parsed 完成后才调用 init。

2.3 main 也遵守相同规则

main 包先完成所有包级变量和 init，才调用 main.main：

package main

var version = detectVersion()

func init() {
	fmt.Println("init", version)
}

func main() {
	fmt.Println("main")
}

如果 init panic 且没有在同一 goroutine 的有效 deferred call 中 recover，main 根本不会开始。

2.4 初始化是顺序执行的

规范规定包初始化按单个 goroutine 顺序进行。init 可以启动新 goroutine，但初始化流程不会等待它完成。这样做通常制造启动竞态：

var ready atomic.Bool

func init() {
	go func() {
		load()
		ready.Store(true)
	}()
}

main 开始时 ready 可能仍为 false。需要异步预热时，在 main 或显式 Run 中启动，并返回可等待、可取消、可报告错误的句柄。

3. 包级变量的依赖顺序

3.1 依赖优先，不只是文本顺序

var a = b + 1
var b = 41

a 依赖 b，因此先初始化 b，再初始化 a，最终 a == 42。依赖来自初始化表达式或函数/方法体中对其他包级变量的引用，规范定义了依赖分析。

var a = f()
var b = 41

func f() int {
	return b + 1
}

a 的初始化依赖 b。

3.2 无依赖变量的顺序

包级变量按声明在包中呈现的顺序逐步选择可初始化项。一个包可以由多个文件组成；构建系统应以确定的词法文件名顺序向编译器提供文件，但这不是让业务依赖文件名排序的理由。

不要写：

text

00_registry.go 必须先于 99_handlers.go 才正确

应该通过显式变量引用建立依赖，或者更好地在构造函数中装配。

3.3 初始化环

包不能循环导入，包级变量也不能形成初始化环：

// var a = b + 1
// var b = a + 1

编译器会报告初始化循环。遇到这种问题，不要用 init 和全局指针绕过去；通常需要重新划分包职责或将状态改为显式构造。

3.4 零值先存在

在执行显式初始化前，包级变量已有类型零值。因此初始化表达式能引用某些结构，但合法顺序仍由依赖规则约束。不要利用半初始化全局状态做隐式协议。

4. init 函数的规则

init 是特殊声明：

func init() {
	// ...
}

限制：

函数名必须是 init；
不能有参数；
不能有结果；
不能声明类型参数；
不能被代码引用或调用；
每个源文件可以声明多个；
包可以有任意多个 init；
声明但未使用的包级 func init 不受普通未使用检查影响。

下面都不合法：

// func init() error { return nil }
// func init(config Config) {}
// var start = init

4.1 多个 init

func init() {
	registerA()
}

func init() {
	registerB()
}

同一文件按源码顺序执行；多个文件依赖编译器接收文件的确定顺序。把强顺序要求写成一个 init：

func init() {
	registerA()
	registerB()
}

不过一旦“注册”可能失败，更适合显式函数返回 error。

4.2 init 无法返回错误

这里真正限制设计的是：init 无法返回错误。初始化若依赖环境变量、网络、文件或数据库，失败后只能 panic、记录后继续，或者把失败藏进全局状态。无论选哪一种，调用方都失去了决定如何处理失败的机会。

func NewConfig() (Config, error) {
	// 调用者决定记录、重试、使用默认值还是退出
}

显式构造比 init 更容易测试，也能接收 context 和依赖。

5. 空白导入与注册模式

空白导入只为了包的初始化副作用：

import _ "image/png"

导入 image/png 会运行它的 init，把 PNG 解码器注册到 image 包。之后通用的 image.Decode 能识别 PNG。

数据库驱动也是经典模式：

import (
	"database/sql"
	_ "example.com/driver"
)

5.1 为什么它能工作

驱动包依赖一个中心 registry，在 init 中调用注册函数。主程序只需导入驱动包即可触发注册。

5.2 代价

从调用点看不见依赖；
失败无法返回；
测试难替换；
导入一个包就改变全局状态；
插件集合由编译链接决定，运行时配置较弱；
重复注册和名称冲突通常要 panic 或全局处理。

空白导入应配注释说明副作用：

import _ "image/png" // 注册 PNG 解码器

在应用内部，优先显式注册：

registry := NewRegistry()
if err := registry.Register("png", NewPNGDecoder()); err != nil {
	return err
}

库生态需要解耦编译期插件时，init 注册仍有价值；普通业务依赖不必模仿。

6. init 的适用场景与反模式

6.1 相对合适

纯内存、确定性、不会失败的表构建；
标准化的编译期注册机制；
验证由常量或生成代码构成的不变量，失败代表构建产物有 bug；
极少量无法通过字面量表达的包级准备。

var hexTable [256]byte

func init() {
	for i := range hexTable {
		hexTable[i] = 0xff
	}
	for i := byte('0'); i <= '9'; i++ {
		hexTable[i] = i - '0'
	}
}

即便如此，也可评估生成代码、数组字面量或惰性初始化是否更明确。

6.2 不适合

读取环境变量或配置文件；
发网络请求；
连接数据库；
启动无法停止的 goroutine；
写日志、修改工作目录、创建业务文件；
根据机器环境决定包的核心行为；
把测试夹具塞入全局变量；
用 panic 报告用户输入错误。

6.3 显式应用装配

func run(ctx context.Context, env map[string]string) error {
	config, err := LoadConfig(env)
	if err != nil {
		return fmt.Errorf("加载配置: %w", err)
	}

	db, err := OpenDatabase(ctx, config.Database)
	if err != nil {
		return fmt.Errorf("连接数据库: %w", err)
	}
	defer db.Close()

	app := NewApp(config, db)
	return app.Run(ctx)
}

func main() {
	if err := run(context.Background(), envMap()); err != nil {
		fmt.Fprintln(os.Stderr, err)
		os.Exit(1)
	}
}

run 可测试、可返回错误，资源生命周期也清楚。os.Exit 只在 main 最外层调用，避免绕过 run 中的 defer。

6.4 惰性初始化

昂贵且不一定使用的只读状态可用 sync.OnceValue、sync.OnceValues 或 sync.Once：

var loadRules = sync.OnceValues(func() (*Rules, error) {
	return parseEmbeddedRules()
})

func Ruleset() (*Rules, error) {
	return loadRules()
}

OnceValues 会缓存结果，包括 error。如果失败需要重试，它不合适，应设计带锁的状态机或由调用者显式重建。

7. defer 的执行模型

7.1 登记而不是立即执行

func Example() {
	defer fmt.Println("later")
	fmt.Println("now")
}

输出：

text

now
later

执行 defer 语句时，会立即求值被调用的函数值和实参，并把调用登记到当前函数调用；真正调用发生在当前函数即将返回时。

7.2 哪些退出会执行

当前函数在以下情况下会执行已登记 defer：

到达函数末尾；
执行 return；
发生 panic 并展开该函数栈帧；
当前 goroutine 调用 runtime.Goexit。

以下情况不会正常执行：

os.Exit 立即终止进程；
log.Fatal 最终调用 os.Exit；
进程被不可处理的外部终止；
运行时致命错误直接结束进程时不能依赖清理；
机器断电或进程被强制杀死。

defer 是进程内控制流保证，不是持久化事务保证。关键数据要使用 fsync、数据库事务、幂等协议等机制。

7.3 defer 属于函数调用，不属于块

func Process() {
	if condition {
		defer cleanup()
	}
	// cleanup 在 Process 返回时执行，不在 if 块结束时
}

这条规则解释了循环内 defer 为什么会积累。

8. 参数、receiver 与闭包的求值时机

8.1 普通参数立即求值

func Example() {
	value := 1
	defer fmt.Println(value)
	value = 2
}

打印 1，因为 defer 登记时已经复制实参。

8.2 闭包在执行时读取捕获变量

func Example() {
	value := 1
	defer func() {
		fmt.Println(value)
	}()
	value = 2
}

打印 2，闭包捕获变量，函数体在退出时才读取。

两种写法没有绝对优劣。需要保存登记时的快照，就传参数；需要读取函数退出前的最终状态，就用闭包。代码应当把这个意图直接写出来。

8.3 函数值立即求值

cleanup := func() { fmt.Println("A") }
defer cleanup()

cleanup = func() { fmt.Println("B") }

输出 A。defer 登记时保存了当时的函数值。

8.4 方法 receiver 立即求值

receiver 也是调用的一部分：

type Counter struct{ Value int }

func (c Counter) Print() {
	fmt.Println(c.Value)
}

func Example() {
	c := Counter{Value: 1}
	defer c.Print()
	c.Value = 2
}

值 receiver 被复制，打印 1。若方法是指针 receiver，登记时复制指针，执行时读取同一对象，通常会看到 2：

func (c *Counter) PrintPtr() {
	fmt.Println(c.Value)
}

因此不能只记住“defer 参数立即求值”，receiver 同样属于这次调用，也要一起分析。

8.5 defer 的返回值被丢弃

deferred 函数可以有结果，但调用结果不会被使用：

defer file.Close() // Close 的 error 被丢弃

若错误重要，必须在闭包中处理或合并。

9. LIFO 与资源栈

同一函数内，defer 按后进先出执行：

defer fmt.Println("first")
defer fmt.Println("second")
defer fmt.Println("third")

输出 third、second、first。

这自然形成资源栈：

file, err := os.Open(path)
if err != nil {
	return err
}
defer file.Close()

gz, err := gzip.NewReader(file)
if err != nil {
	return err
}
defer gz.Close()

后创建的 gz 先关闭，底层 file 后关闭，正好与建立顺序相反。

9.1 解锁模式

mu.Lock()
defer mu.Unlock()

// 多个 return 或 panic 路径都能解锁

defer 必须紧跟成功获取资源之后，减少中间新增 return 导致泄漏的风险。

不要在 Lock 前 defer Unlock：

// defer mu.Unlock()
// mu.Lock()

如果 Lock 前发生 panic，会尝试解锁未持有的 mutex。

9.2 嵌套事务

资源的关闭顺序要按协议设计，不能只依赖“反过来总是对”。例如 buffered writer 必须先 Flush，再关闭底层文件：

file, err := os.Create(path)
if err != nil {
	return err
}
defer file.Close()

writer := bufio.NewWriter(file)
defer writer.Flush() // 后登记，先执行

但 Flush 和 Close 都会返回 error，单纯 defer 会丢失错误；下一节给出完整处理。

10. 返回值、命名结果与错误合并

10.1 return 的准确顺序

执行 return 时：

求值 return 表达式；
把结果赋给函数的结果参数；
执行 defer，按 LIFO；
函数真正返回给调用者。

因此 defer 可以修改命名结果：

func Double() (result int) {
	defer func() {
		result *= 2
	}()
	return 21
}

返回 42。这个能力适合统一错误包装或合并关闭错误，不宜拿来隐藏正常业务计算。

10.2 合并 Close 错误

func Write(path string, data []byte) (err error) {
	file, err := os.Create(path)
	if err != nil {
		return fmt.Errorf("创建 %q: %w", path, err)
	}
	defer func() {
		err = errors.Join(err, file.Close())
	}()

	if _, err = file.Write(data); err != nil {
		return fmt.Errorf("写入 %q: %w", path, err)
	}
	return nil
}

errors.Join(nil, nil) 返回 nil；一个或多个错误非 nil 时，返回可被 errors.Is/As 遍历的组合错误。

10.3 只在成功时采用 Close 错误

有些 API 更希望保留主错误，只有主体成功时才返回关闭错误：

defer func() {
	if closeErr := file.Close(); err == nil {
		err = closeErr
	}
}()

哪种策略正确取决于 API：组合错误保留信息；只保留主错误兼容某些调用约定。文档和测试要明确。

10.4 显式关闭的场景

必须在函数中途确认提交、刷新或关闭是否成功时，直接调用：

if err := writer.Flush(); err != nil {
	return err
}
if err := file.Close(); err != nil {
	return err
}

避免同时 defer 同一资源的 Close，除非 Close 明确幂等且你有意把它作为兜底。常用模式是登记一个根据状态决定是否清理的闭包。

11. 文件、锁、事务与 HTTP Body

11.1 文件

读取文件时 Close 错误通常不影响已读数据，但仍可能值得记录。写文件时 Close 可能暴露延迟写入错误，不能轻易忽略。

11.2 mutex 与 RWMutex

func (c *Cache) Get(key string) (Value, bool) {
	c.mu.RLock()
	defer c.mu.RUnlock()

	value, ok := c.values[key]
	return value, ok
}

不要在持锁状态调用不受控回调、网络 I/O 或可能长时间阻塞的函数。defer 让解锁安全，但不会让临界区自动变短。

复制快照后尽快解锁：

c.mu.RLock()
snapshot := maps.Clone(c.values)
c.mu.RUnlock()

return slowEncode(snapshot)

11.3 数据库事务

一种稳健模式是默认回滚，成功时显式提交：

func Transfer(ctx context.Context, db *sql.DB) (err error) {
	tx, err := db.BeginTx(ctx, nil)
	if err != nil {
		return err
	}
	defer func() {
		err = errors.Join(err, tx.Rollback())
	}()

	if err := debit(ctx, tx); err != nil {
		return err
	}
	if err := credit(ctx, tx); err != nil {
		return err
	}
	return tx.Commit()
}

标准 database/sql 中，提交成功后 Rollback 会返回 sql.ErrTxDone；不能无脑把这个预期错误 Join 到成功结果。更合适：

defer func() {
	if rollbackErr := tx.Rollback(); rollbackErr != nil &&
		!errors.Is(rollbackErr, sql.ErrTxDone) {
		err = errors.Join(err, rollbackErr)
	}
}()

或者只把 Rollback 作为 best effort。事务封装应统一这个策略，避免每个业务函数自行发挥。

11.4 HTTP Response.Body

response, err := client.Do(request)
if err != nil {
	return err
}
defer response.Body.Close()

收到非 nil response 后及时 defer Close。是否需要读完 body 才能复用连接、最大读取量如何限制，应按当前 net/http 文档和业务协议处理。不要无界 io.ReadAll 外部响应。

11.5 获取失败后不要 defer

file, err := os.Open(path)
if err != nil {
	return err
}
defer file.Close()

defer 必须放在确认资源获取成功之后。许多返回值失败时为 nil，直接 defer 会在退出时再次 panic，掩盖原错误。

12. 循环中的 defer

defer 绑定外围函数，所以循环中会积累：

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

大量文件会一直保持打开到 Process 返回。提取函数：

func processOne(path string) error {
	file, err := os.Open(path)
	if err != nil {
		return err
	}
	defer file.Close()

	return consume(file)
}

func Process(paths []string) error {
	for _, path := range paths {
		if err := processOne(path); err != nil {
			return fmt.Errorf("处理 %q: %w", path, err)
		}
	}
	return nil
}

也可以在循环体中使用立即调用函数字面量建立函数边界：

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

命名辅助函数通常更易测试和阅读。

13. panic 的语义

13.1 panic 做什么

panic(value)

当前函数停止正常执行，开始执行它的 defer；随后返回到调用者，调用者也执行 defer，如此沿当前 goroutine 的调用栈展开。若最终没有 recover，程序打印 panic 值和栈信息并终止。

13.2 语言和运行时 panic

除显式 panic 外，许多错误会 panic：

数组或 slice 越界；
nil 指针解引用；
向关闭 channel 发送；
关闭 nil 或已关闭 channel；
向 nil map 赋值；
类型断言不使用 comma-ok 且失败；
调用 nil 函数；
某些并发 map 误用导致运行时致命错误。

并非所有运行时致命情况都能 recover。不要把 recover 当作安全沙箱。

13.3 何时使用

适合：

内部不变量被破坏，继续执行只会产生错误结果；
“Must” 风格构造器处理开发期固定输入；
模板、regexp 的 MustCompile 类便捷入口；
极深内部实现用 panic 简化不可恢复控制流，并在同一包边界转换为 error（需谨慎）。

不适合：

文件不存在；
用户输入非法；
网络超时；
数据库返回冲突；
任何调用者合理预期并需要处理的失败。

库函数默认返回 error。panic 会跨越调用方的普通错误处理路径，属于更强的契约。

13.4 `panic(nil)`

从 Go 1.21 起，在默认设置下执行 panic(nil)，recover 得到非 nil 的运行时值（*runtime.PanicNilError），从而避免“正在 panic 却 recover 返回 nil”的歧义。旧兼容行为可受 GODEBUG=panicnil=1 影响，但新代码不要依赖该开关。

14. recover 的严格边界

14.1 必须在 deferred function 中调用

func Safe(fn func()) (panicked bool, value any) {
	defer func() {
		if recovered := recover(); recovered != nil {
			panicked = true
			value = recovered
		}
	}()

	fn()
	return false, nil
}

recover 在当前 goroutine 正因 panic 展栈，并且由 deferred function 调用时才停止 panic。普通位置调用返回 nil：

fmt.Println(recover()) // nil

14.2 不要藏进普通 helper

func handlePanic() any {
	return recover()
}

func f() {
	defer func() {
		_ = handlePanic() // recover 不是由 deferred function 直接调用，不能按预期工作
	}()
	panic("boom")
}

把 recover() 放在 defer 函数字面量自身，并将恢复值传给 helper：

defer func() {
	if recovered := recover(); recovered != nil {
		reportPanic(recovered, debug.Stack())
	}
}()

14.3 只能恢复同一 goroutine

父 goroutine 无法 recover 子 goroutine：

defer recoverHere() // 捕获不到下面 goroutine 的 panic

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

需要隔离任务 panic，就在任务 goroutine 内部设置 defer：

go func() {
	defer func() {
		if recovered := recover(); recovered != nil {
			report(recovered, debug.Stack())
		}
	}()
	runTask()
}()

14.4 恢复后函数怎样继续

recover 成功后，发生 panic 的函数不会从 panic 点继续执行。栈展开停止在执行 recover 的 deferred function 所属函数，该函数在 defer 完成后返回。

因此 recover 是边界转换，不是“忽略异常继续下一行”。

14.5 恢复后要做什么

一个合理的恢复边界通常要：

记录 panic 值；
保存当前栈 debug.Stack()；
附带请求、任务或插件标识；
将该工作单元标记为失败；
释放资源；
判断进程状态是否仍可信；
对外返回不泄漏内部细节的错误。

静默 recover：

defer func() { _ = recover() }()

几乎总是错误，会把数据损坏和程序 bug 伪装成成功。

14.6 recover 不是 error 包装器

不要对每个函数加 recover。它会让正常错误路径变得不可见，也可能在状态已经部分修改后继续服务。典型边界是 HTTP 请求入口、worker 单任务入口、插件调用入口，而不是每一层。

15. goroutine、os.Exit 与 Goexit

15.1 每个 goroutine 有自己的 defer 栈

一个 goroutine 正常返回，只执行它自己调用栈上的 defer。不会执行创建它的函数的 defer，反之亦然。

main 返回会直接结束进程，不等待其他 goroutine，也不保证它们的 defer 执行。应用需要显式等待：

var wg sync.WaitGroup
wg.Add(1)
go func() {
	defer wg.Done()
	defer cleanup()
	work()
}()
wg.Wait()

15.2 os.Exit

func main() {
	defer fmt.Println("不会打印")
	os.Exit(1)
}

os.Exit 立即终止，defer 不运行。推荐把可失败逻辑放在 run()：

func main() {
	if err := run(); err != nil {
		fmt.Fprintln(os.Stderr, err)
		os.Exit(1)
	}
}

run 返回前完成自己的 defer，然后 main 再决定退出码。

log.Fatal、slog 中自行封装的 Fatal 风格函数如果调用 os.Exit，也有同样问题。库代码不应调用 os.Exit。

15.3 runtime.Goexit

runtime.Goexit 终止调用它的 goroutine，并执行该 goroutine 的 defer，但它不是 panic，defer 中 recover 返回 nil。testing.T.FailNow/Fatal 的控制行为建立在 Goexit 上，因此测试辅助函数必须在测试 goroutine 中调用需要的 Fatal 方法。

Goexit 之后该 goroutine 不会继续；若 main goroutine Goexit 而其他 goroutine 最终也结束，运行时可能报告 deadlock，而不是像 main return 那样正常退出。

16. 性能与编译器优化

16.1 defer 的成本已经很低，但不是零

现代 Go 编译器会对许多静态可知的 defer 做 open-coded 优化，使常见函数退出路径的开销很小。是否采用优化、具体成本和限制属于编译器实现，可能随版本变化。

工程结论：

正确性和可维护性优先，资源获取后直接 defer；
不要根据十年前的 benchmark 禁用所有 defer；
极热的纳秒级函数中，用当前版本和真实调用形态 benchmark；
循环动态登记大量 defer 既有性能成本，也往往有资源生命周期错误。

16.2 如何测

func BenchmarkDefer(b *testing.B) {
	for b.Loop() {
		withDefer()
	}
}

运行：

bash

go test -bench=Defer -benchmem -count=10

比较应保证两个实现语义一致，避免一个版本省略 panic 路径清理。使用 benchstat 分析多轮结果，而不是看一次纳秒数。

16.3 defer 闭包与逃逸

闭包捕获变量不等于一定堆分配。编译器根据逃逸分析决定。诊断：

bash

go build -gcflags='all=-m=2' ./...

不要为了阻止一个未证实的分配，把清晰的错误合并逻辑改成容易漏资源的手工分支。

16.4 init 对启动和测试的成本

init 的时间会直接增加程序启动时间，也影响每个测试二进制。它无法按测试用例选择跳过。昂贵表可生成、嵌入或惰性加载；先通过 trace/profile 测量，再决定。

init 还会影响可重复性：读取当前时间、随机数、环境和机器状态会让测试初始化不可控。纯确定性的初始化更可靠。

17. 测试与可观测性

17.1 init 很难隔离

init 在测试函数之前已经执行，不能为每个测试重跑，也不能正常返回失败。把逻辑移到普通函数：

func buildRegistry(entries []Entry) (*Registry, error)

init 若必须调用它，只保留极薄的一层，测试普通函数。

17.2 测 defer 顺序

func order() (calls []string) {
	defer func() { calls = append(calls, "first") }()
	defer func() { calls = append(calls, "second") }()
	return calls
}

注意 return 表达式与命名 slice header 的求值关系。更直观的测试可把 recorder 指针传入函数，避免测试本身混入返回值语义。

17.3 注入可失败的 closer

type closeFunc func() error

func (fn closeFunc) Close() error {
	return fn()
}

用可控 closer 验证主体错误、关闭错误及组合错误。不要只测试成功路径。

17.4 测 panic

func requirePanic(t *testing.T, fn func()) {
	t.Helper()
	defer func() {
		if recovered := recover(); recovered == nil {
			t.Fatal("期望 panic")
		}
	}()
	fn()
}

若要断言值，优先使用自定义可比较类型或 error，不要依赖运行时 panic 文本的完整格式。标准测试也可直接写局部 defer，使失败位置更明确。

17.5 恢复边界记录栈

panic 值可能不是 error：

defer func() {
	if recovered := recover(); recovered != nil {
		logger.Error(
			"worker panic",
			"panic", recovered,
			"stack", string(debug.Stack()),
		)
	}
}()

日志需避免泄漏敏感参数。服务恢复请求时还应增加 panic counter 和任务失败指标。

18. 与 Java 的对照

Java	Go	关键差异
static field initializer	包级变量初始化	Go 按包依赖图初始化
static initializer block	`init()`	Go init 无参数、无返回且不能调用
SPI / driver auto registration	blank import + init	都有隐式注册代价
`finally`	`defer`	defer 属于函数调用，登记时求值参数
try-with-resources	获取后 `defer Close()`	Go Close error 需显式处理
monitor / lock finally unlock	Lock 后 defer Unlock	Go 不依赖单出口
exception	`panic`	普通业务失败使用 error
catch	`recover`	只在当前 goroutine 的 deferred function 中有效
`System.exit`	`os.Exit`	都不会走正常清理路径
uncaught exception handler	goroutine 入口 recover	Go panic 不跨 goroutine 捕获

Java try-with-resources 会按逆序关闭并处理 suppressed exceptions。Go 的 defer 也按逆序，但不会自动把 Close() 的 error 附加到主 error；要用命名结果和 errors.Join 明确实现。

19. Go 1.22–1.26 相关变化

Go 1.22 到 1.26 没有改变本章所述 init 顺序、defer 的参数求值、LIFO、return 顺序或 recover 的基本边界。相关的版本背景：

Go 1.22 的每轮循环变量会影响循环中登记闭包 defer 时捕获的是哪个变量；但 defer 仍等外围函数返回才执行；
Go 1.22 的整数 range、Go 1.23 的函数迭代器，让“循环中资源何时关闭”更常见，原则仍是用函数边界缩短生命周期；
panic(nil) 的默认非 nil recover 值来自 Go 1.21，1.22–1.26 延续该行为；
编译器会持续优化 defer、内联和逃逸，但 release notes 中的实现改进不等于语言保证。

截至 Go 1.26，init 仍不能返回 error，Go 仍没有析构器或确定性的对象生命周期回调，os.Exit 仍不会执行 defer。涉及资源正确性的代码不能假设“新版本会自动处理”。

20. 常见误区

把 init 当应用启动入口：应在 main/run 中显式装配并返回错误。
在 init 连接数据库或发请求：失败、超时、取消和测试都难控制。
依赖文件名保证 init 顺序：用显式调用或依赖关系。
init 启动 goroutine，认为 main 会等待：初始化流程不会等待它。
认为 defer 参数在退出时求值：函数值、receiver 和实参在登记时求值。
认为 defer 在花括号结束时执行：它在当前函数调用退出时执行。
循环内不断 defer Close：资源积累到外围函数返回。
无条件忽略 Close/Flush/Commit 错误：写路径可能丢数据。
先 defer Close 再检查获取错误：退出时可能 nil dereference。
忘记 LIFO：后登记先执行，资源顺序要验证。
用 defer 修改普通未命名返回表达式：只有结果参数在 defer 执行前已经就位；要修改需命名结果或其他共享位置。
以为 recover 放在哪都行：只能在正在 panic 的 goroutine 的 deferred function 中有效。
父 goroutine recover 子 goroutine：做不到，边界放在子 goroutine 内。
recover 后期待从 panic 下一行继续：发生 panic 的函数不会恢复到原位置。
静默吞 panic：至少记录值和栈，并把工作单元标为失败。
用 panic 表示用户错误：返回 error。
在 main defer 后调用 os.Exit：defer 不执行；把逻辑放进 run。
认为 defer “一定很慢”：用当前工具链测真实热点。

21. 速查表

init

var table = buildTable()

func init() {
	register(table)
}

能显式构造时优先：

func NewApp(ctx context.Context, config Config) (*App, error)

defer

resource, err := acquire()
if err != nil {
	return err
}
defer resource.Close()

参数快照：

defer log(value)

退出时取最终变量：

defer func() { log(value) }()

错误合并：

func work() (err error) {
	resource, err := acquire()
	if err != nil {
		return err
	}
	defer func() {
		err = errors.Join(err, resource.Close())
	}()
	return use(resource)
}

recover 边界

func guarded(fn func()) (err error) {
	defer func() {
		if recovered := recover(); recovered != nil {
			err = fmt.Errorf("panic: %v", recovered)
		}
	}()
	fn()
	return nil
}

真实服务还要记录 debug.Stack()。至于恢复后是否继续运行，要由这个边界所保护的状态是否仍可信来决定。

main

func main() {
	if err := run(); err != nil {
		fmt.Fprintln(os.Stderr, err)
		os.Exit(1)
	}
}

可运行示例

这一节用三个独立程序验证前面的执行模型。它们不依赖输入、网络或外部服务，可以直接在仓库根目录运行。页面展示的源码来自 examples/ch08，CI 编译的也是同一份代码。

示例一：亲眼确认变量、init 与 main 的顺序

先看执行顺序。 “包级变量先初始化，随后执行 init，最后才是 main”很容易停留在背诵层面。这个程序用一个事件切片记录三个阶段，并让第二个变量显式依赖第一个变量。

package main

import "fmt"

var events []string

// first 的初始化表达式先执行。把记录动作放进函数，是为了直接观察
// “包级变量初始化”发生在 init 和 main 之前，而不是依赖日志时间猜测。
var first = record("变量 first")

// second 依赖 first，因此只有 first 完成后才能计算。
// 生产代码不应让初始化顺序承载业务通信；这里的副作用仅用于教学。
var second = record("变量 second（依赖 " + first + "）")

func record(event string) string {
	events = append(events, event)
	return event
}

func init() {
	// init 运行时，本包所有包级变量都已经完成初始化。
	events = append(events, "init")
}

func main() {
	events = append(events, "main")
	for index, event := range events {
		fmt.Printf("%d. %s\n", index+1, event)
	}

	// 避免 second 只为制造依赖而显得晦涩；它确实是程序状态的一部分。
	_ = second
}

运行：

bash

go run ./examples/ch08/init-order

预期输出：

text

1. 变量 first
2. 变量 second（依赖 变量 first）
3. init
4. main

运行时会依次发生这些事。

events 先得到零值，之后 first 调用 record。
second 的表达式读取 first，所以必须等 first 初始化完成。
所有包级变量就绪后才进入 init，所有 init 完成后运行 main。

进一步验证。 再声明一个不依赖 first 的包级变量并记录事件，观察它在当前单文件中的位置。随后把它移到另一个文件中。跨文件顺序不适合作为业务协议；真正需要先后关系时，应写出数据依赖或在 main 中显式装配。

示例二：defer 到底在什么时候读取变量

需要解释的现象。 普通参数和闭包都写在 defer 后面，却可能看到不同的变量值；多个 defer 又会逆序执行。这个例子把“登记时求值”和“退出时执行”拆开观察。

package main

import "fmt"

func main() {
	label := "登记时的值"

	// defer 的普通参数现在就求值并保存，因此稍后修改 label 不会改变它。
	defer fmt.Println("普通参数：", label)

	// 闭包保存的是变量本身，函数真正退出时才读取 label。
	// 这在循环或共享状态中很容易制造“最后一次值”的误解。
	defer func() {
		fmt.Println("闭包读取：", label)
	}()

	label = "退出时的值"

	// defer 按后进先出执行：这个调用最后登记，却最先运行。
	defer fmt.Println("LIFO：最后登记，最先执行")

	fmt.Println("函数体结束")
}

运行：

bash

go run ./examples/ch08/defer-evaluation

预期输出：

text

函数体结束
LIFO：最后登记，最先执行
闭包读取： 退出时的值
普通参数： 登记时的值

重点看三处。

defer fmt.Println(..., label) 在登记时复制实参，所以保留旧字符串。
deferred closure 在函数退出时才读取捕获变量，所以看到新字符串。
三个调用按后进先出执行。资源之间若有依赖，应按“先获得外层、再获得内层”的顺序登记清理。

可以继续验证。 把闭包改成 func(value string) { ... }(label)，它会像普通参数一样保留登记时的值。再交换三个 defer 的书写顺序，先预测输出，再运行验证。

示例三：清理失败不能覆盖原始错误

为什么不能只返回最后一个错误。 主流程已经失败，两个资源的 Close 也失败时，只保留最后一个错误会丢掉关键证据。这个程序用命名返回值和 errors.Join 保存完整错误链。

package main

import (
	"errors"
	"fmt"
)

type resource struct {
	name string
}

func (r resource) Close() error {
	// 真实文件、压缩流和网络连接的 Close 都可能失败，不能一律忽略。
	return fmt.Errorf("关闭 %s 失败", r.name)
}

func useResource() (err error) {
	outer := resource{name: "外层资源"}
	defer func() {
		// 命名返回值让 deferred closure 能把清理失败合并进原错误。
		// errors.Join 会保留两条错误链，调用者仍可用 errors.Is/As 检查。
		err = errors.Join(err, outer.Close())
	}()

	inner := resource{name: "内层资源"}
	defer func() {
		// 内层后获取、先关闭，符合资源栈的 LIFO 关系。
		err = errors.Join(err, inner.Close())
	}()

	return errors.New("处理数据失败")
}

func main() {
	fmt.Printf("最终错误：\n%v\n", useResource())
}

运行：

bash

go run ./examples/ch08/defer-error-join

预期输出：

text

最终错误：
处理数据失败
关闭 内层资源 失败
关闭 外层资源 失败

错误是这样汇总的。

外层资源先获得并先登记 defer，内层资源后获得并后登记。
退出时先关闭内层，符合依赖资源的 LIFO 生命周期。
每次清理都用 errors.Join(err, closeErr) 更新命名返回值，不覆盖此前失败。

再做两个改动。 让其中一个 Close 返回 nil，确认 errors.Join 不会凭空制造错误；再把主流程改成成功返回，观察清理错误仍会成为最终错误。

22. 练习

建三个小包记录初始化事件，构造菱形依赖，验证每个包只初始化一次、依赖先于使用者。不要让业务正确性依赖兄弟包顺序。
把一个在 init 中读取环境变量并 panic 的配置包改成 Load(env) (Config, error)，让测试覆盖缺失、非法和默认值。
写示例分别 defer 普通参数、闭包和值/指针 receiver，修改原变量后验证输出，并用“登记时”和“执行时”解释。
实现压缩文件写入：buffer Flush、gzip Close、file Close 都可能失败。设计顺序并用 errors.Join 保留多个错误。
构造循环打开大量文件的错误实现，在低文件描述符限制下复现，再提取 processOne 修复。
实现事务 helper：回调成功则 Commit，失败或 panic 则 Rollback；panic 完成回滚后要继续传播。处理 sql.ErrTxDone。
实现 worker 边界，捕获单任务 panic，记录栈并返回结构化失败；证明其他任务仍能继续，同时说明哪些共享状态损坏时不应恢复。
写测试验证父 goroutine 无法 recover 子 goroutine panic；再把恢复边界移到子 goroutine。测试时注意不要让未恢复 panic 杀死整个测试进程，可在辅助子进程中验证。
比较 defer 解锁与显式解锁的 benchmark，使用当前 Go 版本多轮运行；再解释为什么正确性优先于纳秒差异。
写 run() error 形式的 CLI，确保临时文件和 profiler 在返回时关闭，再由 main 选择退出码。对比直接在深层调用 log.Fatal 的问题。

23. 官方资料

init 决定隐式启动成本，defer 决定显式资源边界，recover 决定异常能否被隔离。工程上最稳妥的原则是：初始化尽量显式、资源获取后立即登记清理、panic 只在少数边界恢复，并且任何恢复都不能抹掉失败证据。

Go init 与 defer：初始化顺序、资源生命周期和 panic 边界 ​

目录

1. 先建立时间线 ​

2. 包初始化的完整顺序 ​

2.1 依赖包先于当前包 ​

2.2 一个包内部 ​

2.3 main 也遵守相同规则 ​

2.4 初始化是顺序执行的 ​

3. 包级变量的依赖顺序 ​

3.1 依赖优先，不只是文本顺序 ​

3.2 无依赖变量的顺序 ​

3.3 初始化环 ​

3.4 零值先存在 ​

4. init 函数的规则 ​

4.1 多个 init ​

4.2 init 无法返回错误 ​

5. 空白导入与注册模式 ​

5.1 为什么它能工作 ​

5.2 代价 ​

6. init 的适用场景与反模式 ​

6.1 相对合适 ​

6.2 不适合 ​

6.3 显式应用装配 ​

6.4 惰性初始化 ​

7. defer 的执行模型 ​

7.1 登记而不是立即执行 ​

7.2 哪些退出会执行 ​

7.3 defer 属于函数调用，不属于块 ​

8. 参数、receiver 与闭包的求值时机 ​

8.1 普通参数立即求值 ​

8.2 闭包在执行时读取捕获变量 ​

8.3 函数值立即求值 ​

8.4 方法 receiver 立即求值 ​

8.5 defer 的返回值被丢弃 ​

9. LIFO 与资源栈 ​

9.1 解锁模式 ​

9.2 嵌套事务 ​

10. 返回值、命名结果与错误合并 ​

10.1 return 的准确顺序 ​

10.2 合并 Close 错误 ​

10.3 只在成功时采用 Close 错误 ​

10.4 显式关闭的场景 ​

11. 文件、锁、事务与 HTTP Body ​

11.1 文件 ​

11.2 mutex 与 RWMutex ​

11.3 数据库事务 ​

11.4 HTTP Response.Body ​

11.5 获取失败后不要 defer ​

12. 循环中的 defer ​

13. panic 的语义 ​

13.1 panic 做什么 ​

13.2 语言和运行时 panic ​

13.3 何时使用 ​

13.4 panic(nil) ​

14. recover 的严格边界 ​

14.1 必须在 deferred function 中调用 ​

14.2 不要藏进普通 helper ​

14.3 只能恢复同一 goroutine ​

14.4 恢复后函数怎样继续 ​

14.5 恢复后要做什么 ​

14.6 recover 不是 error 包装器 ​

15. goroutine、os.Exit 与 Goexit ​

15.1 每个 goroutine 有自己的 defer 栈 ​

15.2 os.Exit ​

15.3 runtime.Goexit ​

16. 性能与编译器优化 ​

16.1 defer 的成本已经很低，但不是零 ​

16.2 如何测 ​

16.3 defer 闭包与逃逸 ​

16.4 init 对启动和测试的成本 ​

17. 测试与可观测性 ​

17.1 init 很难隔离 ​

17.2 测 defer 顺序 ​

17.3 注入可失败的 closer ​

17.4 测 panic ​

17.5 恢复边界记录栈 ​

18. 与 Java 的对照 ​

19. Go 1.22–1.26 相关变化 ​

20. 常见误区 ​

21. 速查表 ​

Go init 与 defer：初始化顺序、资源生命周期和 panic 边界

1. 先建立时间线

2. 包初始化的完整顺序

2.1 依赖包先于当前包

2.2 一个包内部

2.3 main 也遵守相同规则

2.4 初始化是顺序执行的

3. 包级变量的依赖顺序

3.1 依赖优先，不只是文本顺序

3.2 无依赖变量的顺序

3.3 初始化环

3.4 零值先存在

4. init 函数的规则

4.1 多个 init

4.2 init 无法返回错误

5. 空白导入与注册模式

5.1 为什么它能工作

5.2 代价

6. init 的适用场景与反模式

6.1 相对合适

6.2 不适合

6.3 显式应用装配

6.4 惰性初始化

7. defer 的执行模型

7.1 登记而不是立即执行

7.2 哪些退出会执行

7.3 defer 属于函数调用，不属于块

8. 参数、receiver 与闭包的求值时机

8.1 普通参数立即求值

8.2 闭包在执行时读取捕获变量

8.3 函数值立即求值

8.4 方法 receiver 立即求值

8.5 defer 的返回值被丢弃

9. LIFO 与资源栈

9.1 解锁模式

9.2 嵌套事务

10. 返回值、命名结果与错误合并

10.1 return 的准确顺序

10.2 合并 Close 错误

10.3 只在成功时采用 Close 错误

10.4 显式关闭的场景

11. 文件、锁、事务与 HTTP Body

11.1 文件

11.2 mutex 与 RWMutex

11.3 数据库事务

11.4 HTTP Response.Body

11.5 获取失败后不要 defer

12. 循环中的 defer

13. panic 的语义

13.1 panic 做什么

13.2 语言和运行时 panic

13.3 何时使用

13.4 `panic(nil)`

14. recover 的严格边界

14.1 必须在 deferred function 中调用

14.2 不要藏进普通 helper

14.3 只能恢复同一 goroutine

14.4 恢复后函数怎样继续

14.5 恢复后要做什么

14.6 recover 不是 error 包装器

15. goroutine、os.Exit 与 Goexit

15.1 每个 goroutine 有自己的 defer 栈

15.2 os.Exit

15.3 runtime.Goexit

16. 性能与编译器优化

16.1 defer 的成本已经很低，但不是零

16.2 如何测

16.3 defer 闭包与逃逸

16.4 init 对启动和测试的成本

17. 测试与可观测性

17.1 init 很难隔离

17.2 测 defer 顺序

17.3 注入可失败的 closer

17.4 测 panic

17.5 恢复边界记录栈

18. 与 Java 的对照

19. Go 1.22–1.26 相关变化

20. 常见误区

21. 速查表

init