Go中nil指针解引用会直接panic，因其认为对无效地址读写已无继续执行意义；常见于未检查http响应、JSON字段、嵌套指针及接口底层nil值等场景。
为什么 nil 指针解引用会直接 panic
Go 不做空安全兜底，nil 指针一旦被解引用（比如写 *p、访问 p.Field、调用 p.Method() 且方法体里用了字段），运行时立刻崩溃，错误信息固定为：panic: runtime error: invalid memory address or nil pointer dereference。这不是“异常”，而是程序主动中止——因为 Go 认为：对一个未指向有效内存的地址做读写，已经失去继续执行的意义。
哪些场景最容易踩中空指针 panic
常见触发点不是“写了 nil”，而是“忘了检查它是否是 nil”：
-
http.Get()失败后返回nil *http.Response，却直接调用resp.Body.Close() - JSON 反序列化时字段缺失，
*string或*int字段静默置为nil，后续直接*u.Age就崩 - 结构体字段是
*map[string]int，只判了外层指针m != nil，没查内层*m是否也nil - 接口变量值是
*User，但原始指针是nil；此时iface != nil为真，但iface.(*User).Name仍 panic
怎么安全地用指针，而不是靠 recover 补救
recover 是兜底手段，不该是主要防御方式。真正可靠的写法是“显式判空 + 明确路径”：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 所有可能为
nil的来源都必须检查：函数返回值（json.Unmarshal、http.Get）、map 查找（m[key]）、结构体字段（尤其是*T类型） - 双重判空不能省：
if c != nil && c.count != nil { *c.count++ }，漏掉任一层都会 panic - 构造函数统一初始化：
func NewUser() *User { return &User{Age: new(int)} }，比零散new或&User{}更可控 - 用
go vet扫描可疑解引用，它能发现很多未判空就用的模式
容易被忽略的细节：*T 方法能在 nil 上调用，但有陷阱
Go 允许给 *T 定义方法，且该方法可在 nil 指针上调用——前提是方法体内不访问 receiver 的字段或调其他方法。这常被误当作“安全”，但实际很脆弱：
立即学习“go语言免费学习笔记（深入）”；
- 写
func (u *User) GetName() string { return u.Name }：若u == nil，u.Name就 panic - 写
func (c *Counter) Inc() { if c != nil { c.count++ } }：看似防了，但调用方仍可能传nil，而方法内部逻辑已耦合判空 - 更稳妥的是让方法自己处理边界，或文档明确标注 “receiver must not be nil”
*p，但 p 其实来自第 1 层 JSON 解析的遗漏。所以关键不在“怎么 catch”，而在“在哪 check”。 
