Go panic(nil) 还能用 recover 返回 nil 来判断吗

能不能用 recover() == nil 判断 panic，取决于 Go 版本和模块的兼容设置。Go 1.21 默认会把 panic(nil) 变成一个非 nil 的运行时 panic，因此直接 deferred 函数里的 recover 不再因为 nil 参数而返回 nil；但旧模块或显式设置 GODEBUG=panicnil=1 仍可能保留旧语义。

Go 1.21 之后 panic(nil) 为什么不再让 recover 返回 nil

这个变化不是 recover 的返回类型改了，而是运行时先改变了 nil panic 的表现。Go 1.21 的规则要求：如果 goroutine 正在 panicking，且 recover 是由 deferred 函数直接调用的，返回值保证不为 nil。为满足这个保证，panic(nil) 会触发 *runtime.PanicNilError。

判断时不要只看本机安装的 Go 版本，还要看主模块的 go.mod。Go 1.21 发布说明指出，主模块声明 go 1.20 或更早版本时，会自动启用 panicnil=1，这是为了让旧程序平滑运行。

相关规则可以对照 Go 1.21 发布说明、语言规范的 panic 处理 和 builtin recover 文档。

recover 返回 nil 时到底说明了什么

recover 只有在同一个 goroutine 的 deferred 函数中直接调用，才有机会停止 panicking 并取回 panic 值。把它包在另一个普通函数里，或者在没有 panic 时调用，返回 nil 都是正常的。

因此，下面三种情况要分开看：

• 没有发生 panic：当前 goroutine 没有 panicking，返回 nil。
• 位置不正确：recover 不是由 deferred 函数直接调用，返回 nil，也不能停止 panic。
• 旧语义的 panic(nil)：确实发生了 panic，但取回的值仍是 nil。

第三种情况只会让旧代码难以判断；在 Go 1.21 默认语义下，它被运行时的非 nil 值替代。所以“recover() == nil 就代表没有 panic”从来都不是跨版本可靠的协议。

用非 nil 哨兵区分真正的 panic

如果业务确实需要用 panic 作为边界信号，最稳妥的做法是规定 panic 值必须非 nil。普通错误优先用返回值传递；只有跨越插件、任务执行器或请求保护边界时，才集中 recover。

package main

import (
	"errors"
	"fmt"
)

// safeCall 只在边界函数中恢复 panic，并显式返回是否发生过 panic。
func safeCall(fn func()) (panicked bool, value any) {
	defer func() {
		// 直接在 deferred 函数中调用 recover，兼容 Go 1.21 的保证。
		if recovered := recover(); recovered != nil {
			panicked = true
			value = recovered
		}
	}()

	fn()
	return false, nil
}

func main() {
	// 使用非 nil error 作为跨边界的 panic 哨兵。
	panicked, value := safeCall(func() {
		panic(errors.New("配置缺少 endpoint"))
	})
	fmt.Printf("panicked=%v, value=%v\n", panicked, value)
}

这里的关键不是把所有 panic 都吞掉，而是让协议可观察：正常执行返回 false, nil，边界 panic 返回 true 和非 nil 值。若需要区分多种故障，可定义带分类字段的自定义结构体，再用类型断言处理；不要把字符串比较当作长期接口。

兼容旧版本时如何处理 panicnil

短期维护旧项目时，可以在测试或启动环境中明确写出兼容开关：

# 仅用于确认旧模块对 panic(nil) 的兼容行为。
GODEBUG=panicnil=1 go test ./...

这适合迁移窗口，不适合成为新的业务约定。升级时应搜索 panic(nil)、检查 CI 和容器启动参数，并把调用改成 panic(err) 或自定义非 nil 值。还要注意子进程、测试脚本和部署平台可能拥有自己的 GODEBUG；只改开发机环境，不能证明生产行为一致。

最后记住一句速查结论：在 Go 1.21+ 的默认模块语义下，直接 deferred recover 遇到 panic(nil) 不会返回 nil；在旧语义下，nil 仍有歧义。跨版本代码不要依赖这个歧义，改用非 nil panic 值和明确的 panicked 标志。

相关问题

recover 写在普通函数里为什么接不到 panic？

因为它必须由 deferred 函数直接调用；中间再包一层普通函数，就不再满足 recover 的调用条件。

业务错误应该用 panic 还是 error？

可预期的校验、网络和存储错误优先返回 error；panic 只留给不可继续的内部状态或明确的边界保护。