go中无法用recover捕获nil指针解引用引发的panic，因其属于不可恢复的运行时崩溃；recover仅对显式调用panic()触发的用户级panic有效，且必须在defer函数中调用。
Go 里没有空指针“异常”
Go 语言根本不存在空指针异常（NullPointerException）这种运行时 panic，nil 指针解引用会直接触发 panic: runtime error: invalid memory address or nil pointer dereference，但它不是“异常”，而是不可恢复的崩溃信号。你不能靠 recover 拦截它——因为 panic 发生时，栈已经处于不可预测的损坏状态，Go 运行时禁止在非 defer 函数中 recover，更不允许在 nil 解引用这类底层内存错误后安全继续执行。
recover 只对显式 panic 有效
recover 的作用范围非常明确：它只能捕获由 panic() 主动抛出的值，且必须在 defer 函数中调用。常见误用是以为它能兜底所有崩溃，比如：
func badExample() {
var p *int
defer func() {
if r := recover(); r != nil { // 这里永远收不到
log.Println("recovered:", r)
}
}()
fmt.Println(*p) // panic 立即终止函数，defer 甚至没机会执行完
}
上面代码中，*p 触发 panic 后，当前 goroutine 立即停止，defer 函数虽被安排执行，但其内部的 recover() 返回 nil，因为该 panic 不是 Go 语言规范允许 recover 捕获的类型（它是 runtime 强制终止，非用户级 panic）。
真正该做的：预防 nil 解引用
处理 nil 指针的核心思路是主动检查，而不是事后 recover。这既是 Go 的惯用法，也是唯一可靠的方式：
- 所有指针、接口、map、slice、channel 在解引用或调用前，先判断是否为
nil - 函数参数如果是指针，文档和实现中应明确是否接受
nil；不接受就加 early return 检查 - 使用结构体嵌入或组合时，注意内嵌字段可能为
nil，例如req.Header在某些 HTTP 场景下可能是nil，需判空再访问req.Header.Get("X-Trace-ID") - 避免返回裸
nil指针，优先返回零值或封装错误，例如数据库查询无结果时返回user{}, nil而非nil, nil
什么情况下 recover 才值得用
仅限于你**主动控制 panic 流程**的场景，比如：
- HTTP handler 中防止整个服务因单个请求 panic 而退出：
defer func() { if r := recover(); r != nil { http.Error(w, "Internal Error", http.StatusInternalServerError) } }() - 插件系统中隔离不受信代码，用
panic作为可控中断机制，再用recover统一清理资源 - 测试中验证某段逻辑是否 panic：
func TestFooPanics(t *testing.T) { defer func() { if r := recover(); r == nil { t.Fatal("expected panic") } }(); foo() }
这些 case 的共同点是：panic 是你发起的、可预期的、非内存崩溃类的控制流转移。一旦涉及 nil 指针解引用，说明代码已有逻辑漏洞，修复它比绕开它重要得多。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
