本文详解如何对包含 defer 的 go 函数进行单元测试，重点解决 panic 下 defer 是否正确执行的验证问题，并提供可复用的测试策略与代码示例。
在 Go 中，defer 语句的执行时机具有确定性：它总是在其所在函数即将返回（包括因 panic 而提前返回）时按后进先出（LIFO）顺序执行。这一特性使 defer 成为资源清理（如解锁、关闭文件、恢复状态）的理想工具；但同时也给单元测试带来挑战——尤其是当被测函数因 panic 中断执行时，常规的“断言写在调用之后”方式将完全失效。
以 doStuff() 为例，其核心逻辑是：先加锁 → 执行可能 panic 的任务 → 依赖 defer unlock() 确保最终解锁。要验证 unlock() 是否真的被执行，不能在 doStuff() 调用后检查 locked 状态（因为 panic 会跳过后续代码），而必须在 panic 发生后的“清理阶段”进行断言。
✅ 正确策略：将断言逻辑本身 defer，并配合 recover() 捕获 panic
这是测试 defer 行为的关键范式。由于 defer 语句在 panic 后仍会执行，我们可利用这一机制，在 panic 发生前注册两个 defer：
- 一个用于 recover()，阻止 panic 向上冒泡，使测试函数能继续运行；
- 另一个用于执行断言，验证 defer 清理逻辑是否生效（例如 locked == false）。
以下是完整、可运行的测试代码：
func TestDoStuff_UnlocksOnPanic(t *testing.T) {
// Step 1: defer recovery to prevent test failure from panic
defer func() {
if r := recover(); r == nil {
t.Fatal("expected panic, but none occurred")
}
}()
// Step 2: defer assertion — runs *after* doStuff panics, but *before* test function returns
defer func() {
if locked {
t.Error("Expected unlocked (locked = false), but locked =", locked)
}
}()
// Step 3: trigger the tested function
doStuff() // panics here → triggers both deferred funcs in reverse order
}? 注意事项与最佳实践：
- defer 断言必须早于 defer recover() 声明：Go 中 defer 按声明顺序逆序执行。因此，若希望断言在 recover() 之后运行（即确保 panic 已发生且 defer unlock() 已执行），需先声明断言 defer，再声明 recover defer（如上方示例）。否则 recover() 会先执行并清空 panic 状态，导致断言失去上下文。
- 避免副作用干扰：测试前应重置全局状态（如 locked = false），或改用局部状态/接口抽象，提升测试隔离性。本例中建议将 locked 改为包内变量并提供 ResetForTest() 辅助函数。
- 推广到更复杂场景：对于多资源 defer（如 defer close(f) + defer unlock()），可使用计数器或 mock 记录器（如 sync.WaitGroup 或自定义 Logger 接口）验证所有 defer 是否触发。
- 优先重构而非强测 defer：长期来看，应将 lock/unlock 抽象为可注入的接口（如 Locker），在测试中传入带记录能力的 mock 实现，使断言更直观、无需依赖 panic 流程。
总结：测试 defer 的本质，是理解并利用其“函数退出时必执行”的语义。面对 panic，不要试图在 panic 后写代码，而是把验证逻辑“挂载”到 defer 链上——这既是 Go 的设计哲学，也是最稳健的测试之道。
