Go panic 值为 nil 时 recover 为什么读不到

排查 Go 服务的异常日志时，panic(nil) 经常让人误以为 recover 失效了。真正要先确认三件事：运行程序的 Go 版本、recover 是否由同一 goroutine 的 deferred 函数直接调用，以及传入的是 nil 接口还是“装着 nil 指针的接口”。Go 1.21 及以后，直接调用 panic(nil) 会让 recover 得到非 nil 的运行时值；旧版本则可能得到 nil，所以不能只用一个 r != nil 下结论。

“读不到”通常不是 panic 消失，而是版本语义、recover 调用位置或接口判空方式混在了一起。先把这三层拆开，恢复逻辑就能稳定工作。

panic(nil) 的结果先看 Go 版本

规范需要保证：发生 panic 且确实处于可恢复位置时，recover 不能仅因为 panic 参数是 nil 就无法区分“正在 panic”和“没有 panic”。因此 Go 1.21 起，运行时会为 panic(nil) 提供一个非 nil 的 runtime.PanicNilError 值。旧工具链的行为不同，测试代码若固定写成 if recover() != nil，就可能把一次已经发生的 nil panic 误判成“没有读到”。

为了兼容不同环境，先把返回值保存下来，再记录动态类型；不要把“返回值可打印”与“返回值一定非 nil”混为一谈：

package main

import "fmt"

func guarded() {
	defer func() {
		// 直接在 deferred 函数里读取，保留类型信息，便于区分版本行为。
		value := recover()
		fmt.Printf("recovered=%v type=%T isNil=%v\n", value, value, value == nil)
	}()

	// Go 1.21+ 会为 nil 参数提供非 nil 的运行时 panic 值。
	panic(nil)
}

func main() {
	guarded() // 恢复后回到调用者，示例只演示边界，不把 panic 当普通错误。
}

如果线上仍运行旧版本，看到 isNil=true 并不能证明没有进入 panic；应把工具链版本和恢复位置一起记录。

recover 必须站在正确的 deferred 函数里

recover 在普通代码中调用会返回 nil；即使当前 goroutine 正在 panic，只要它不是由正在执行的 deferred 函数直接调用，也没有恢复效果。下面这种“再转一层”的写法容易误判：

func readPanic() any {
	// 这个调用不在 deferred 函数本身的直接调用表达式里，不能依赖它恢复 panic。
	return recover()
}

func wrong() {
	defer func() {
		// 闭包是 deferred 函数，但 recover 被 helper 间接调用，结果不能按恢复值使用。
		fmt.Printf("value=%v\n", readPanic())
	}()
	panic("boom")
}

稳定的做法是让 deferred 闭包直接调用 recover，需要复用时把已取得的值传给普通函数：

func recordPanic(value any) {
	// 普通函数只负责记录已取得的值，不再次调用 recover。
	fmt.Printf("panic type=%T value=%v\n", value, value)
}

func right() {
	defer func() {
		// 直接读取后再交给记录函数，避免丢失恢复上下文。
		if value := recover(); value != nil {
			recordPanic(value)
		}
	}()
	panic("boom")
}

typed nil 进入接口后，判空结果会改变

另一个常见场景是把 nil 指针放进 error 接口。接口值由动态类型和值共同组成；当动态类型存在时，接口本身通常不再等于 nil。于是 panic(err) 后，recover 可能拿到一个类型为 *MyError、底层指针却是 nil 的接口值。

type MyError struct{}

func (*MyError) Error() string { return "示例错误" }

func typedNil() {
	defer func() {
		// 这里的接口可能非 nil，但其中的 *MyError 指针值仍然是 nil。
		value := recover()
		fmt.Printf("type=%T interfaceNil=%v\n", value, value == nil)
	}()

	var err *MyError
	panic(err) // 传给 panic 时形成带动态类型的接口值。
}

因此，排障日志至少应同时输出 %T 和 %v。若业务需要判断具体类型，再使用类型断言并单独判断指针是否为 nil；不要把接口的 == nil 当成底层对象的判空。

一份可落地的恢复检查清单

最后一点很重要：recover 适合隔离真正意外的 panic，例如在请求边界记录故障并终止当前处理；可预期的校验失败、找不到数据和业务拒绝仍应使用显式 error 返回。

常见问题

为什么直接写 defer recover() 仍然看不到日志？

它可能确实触发了恢复，但返回值被丢弃了。需要记录或转换错误时，用 deferred 闭包接收返回值。

panic(nil) 在所有 Go 版本都返回 runtime.PanicNilError 吗？

不是。这个可识别的非 nil 运行时值是 Go 1.21 起的行为，旧版本不能按同样输出判断。

recover 能捕获其他 goroutine 的 panic 吗？

不能。panic 和 recover 都以 goroutine 为边界；要处理工作 goroutine 的异常，应在该 goroutine 自己的入口放置 deferred 恢复逻辑。

为什么推荐记录 %T？

因为接口的动态类型能揭示 typed nil、运行时 panic 值和字符串 panic 的区别，单看格式化后的文字常常不够。

把版本、defer 位置和接口形态分别核对后，panic(nil) 的“recover 读不到”就不再是一个模糊现象：你能明确知道是旧语义、调用位置错误，还是 typed nil 的判空误读。