不会。panic(nil) 会中止当前 goroutine，但不被视为“有值的 panic”，recover() 捕获不到，返回 nil，且不进入 defer 中的 recover 分支逻辑。
panic(nil) 会触发 recover 吗？
不会。这是最常被误判的一点：panic(nil) 确实会中止当前 goroutine，但它**不被视为“有值的 panic”**，recover() 捕获不到它，返回 nil，且不会进入 defer 链的 recover 分支逻辑。
常见错误现象：写了个 defer + recover，以为能兜住所有 panic，结果 panic(nil) 直接 crash，日志里只看到 panic: nil，没走 recover 分支。
- Go 运行时对
panic(nil)的处理是特殊路径，绕过常规 panic 值栈管理 - 只要
recover()返回值是nil，就不能断定没 panic——可能 panic 了但值是 nil - 调试时别只看 defer 是否执行，要加日志确认
recover()的返回值
为什么有人会写 panic(nil)？
多数是误用或简化思维导致：比如想“主动终止但不传信息”，或从其他语言（如 Python 的 raise 不带参数）类比过来；也有人在模板代码里删掉 panic 参数，留下空括号。
使用场景极少，几乎无正当理由——Go 的设计哲学是 panic 应携带可诊断信息，哪怕只是字符串。
立即学习“go语言免费学习笔记（深入）”；
-
panic("unreachable")比panic(nil)更安全、更易 debug - 工具链（如 staticcheck）会警告
panic(nil)，它被明确标记为 “bad practice” - 某些旧版 Go 文档示例曾出现过
panic(nil)，但 1.20+ 已全部替换
recover() 怎么区分 panic(nil) 和正常流程？
不能靠 recover() 返回值是否为 nil 来判断——因为正常没 panic 时它也返回 nil，panic(nil) 时还是 nil。必须借助外部信号。
实际做法是：用一个闭包变量或 channel 在 defer 中做标记。
func example() {
var panicked bool
defer func() {
if r := recover(); r != nil {
// 这里进不来：panic(nil) 不触发此分支
}
if panicked {
log.Println("definitely panicked with nil")
}
}()
defer func() { panicked = true }() // 先注册这个 defer
panic(nil)
}
- 多个 defer 按后进先出执行，把“设标记”的 defer 放在 recover 前面
- 注意：如果中间有其他 panic（非 nil），这个标记会被覆盖，需结合上下文判断
- 生产环境更推荐用
runtime.Stack在 panic 前主动 dump，避免依赖 recover 行为
替代 panic(nil) 的合理方案
真需要终止并保留诊断能力，就别省那个字符串。Go 的 panic 开销本就不高，关键在信息有效性。
- 用
panic(fmt.Sprintf("assertion failed: %v", x))替代裸panic(nil) - 封装成函数：
func must(err error) { if err != nil { panic(err) } }—— 这样既避免 nil panic，又统一了错误出口 - 若只是想“提前退出”，优先用 return + error，panic 应仅用于真正异常、不可恢复的状态
最容易被忽略的是：panic(nil) 在测试中可能被 go test 的 -race 或 -gcflags 静默改变行为，不同版本 Go 对它的堆栈截断策略也不一致——别把它当稳定原语用。
