Go中直接解引用nil指针会panic，因语言不提供隐式空值防护，必须显式检查p != nil；常见陷阱包括嵌套指针未逐级判断、误用* p != 0等，应结合go vet和staticcheck提前发现风险。
为什么直接解引用 nil 指针会 panic
Go 中对 nil 指针解引用（如 *p）不是返回零值，而是立即触发 panic: runtime error: invalid memory address or nil pointer dereference。这和 C/C++ 的未定义行为不同，但同样不可恢复——一旦发生，当前 goroutine 终止。
关键点在于：Go 不做隐式空值防护，nil 检查必须显式写在解引用之前。
- 结构体字段指针、函数参数、map 中存储的指针、切片元素类型为指针时，都可能为
nil -
new(T)和&T{}总是返回非nil指针；但var p *T、make([]*T, n)初始化后的元素、从 map 取值失败时默认零值，都会产生nil指针
if p != nil 是最可靠的基础检查方式
没有捷径，最安全、最清晰、最被 Go 工具链（如 staticcheck）认可的方式就是显式比较：
if p != nil {
fmt.Println(*p)
} else {
fmt.Println("p is nil")
}
注意以下常见陷阱：
立即学习“go语言免费学习笔记（深入）”；
- 不要用
if *p != 0或类似表达式——这本身就会 panic - 不要依赖
fmt.Printf("%v", p)输出来判断是否为空：它打印 - 当指针嵌套多层（如
**T）时，需逐级检查：if p != nil && *p != nil - 在方法接收者中，
(*T).Method允许nil接收者调用，但方法体内若解引用self前未检查，仍会 panic
使用 errors.Is 或自定义错误判断 nil 指针返回值
很多标准库函数（如 json.Unmarshal、database/sql.Rows.Scan）在遇到无效指针时返回 err != nil，而不是让程序崩溃。但有些函数（如自定义解析器）可能直接返回 nil 指针作为“无结果”信号，此时需配合错误值一起判断：
func parseUser(data []byte) (*User, error) {
u := new(User)
if err := json.Unmarshal(data, u); err != nil {
return nil, err
}
// u 不为 nil，但内部字段可能未填充；此处不 panic
return u, nil
}
// 调用方：
u, err := parseUser(b)
if err != nil {
log.Fatal(err)
}
if u == nil { // 显式检查返回值是否为 nil
log.Println("no user parsed")
return
}
fmt.Println(u.Name)
更严谨的做法是让函数返回明确语义的错误，而非裸 nil：
- 避免返回
(*T, nil)表示“不存在”，改用(nil, ErrNotFound) - 若必须返回
nil，文档必须明确说明该nil的含义，并要求调用方检查
借助 go vet 和静态分析提前发现风险
Go 自带的 go vet 无法检测所有 nil 解引用，但它能识别部分明显模式，比如对函数返回的 nil 指针直接解引用：
func bad() *int {
return nil
}
x := *bad() // go vet 可能报告 "possible nil pointer dereference"
更有效的手段是启用 staticcheck（通过 golangci-lint）：
- 检查未使用的指针解引用（如
_ = *p且p可能为nil） - 标记
nil检查位置与实际解引用位置距离过远（易遗漏） - 识别 struct 字段访问前缺少外层指针检查（如
p.F但未先判p != nil）
运行：golangci-lint run --enable=SA5011（对应 nilness 检查器）
真正容易被忽略的是：指针安全不只关乎“有没有 if p != nil”，而在于整个数据流是否可推导。比如从 map[string]*T 中取值，即使加了 if v != nil，如果 map 本身是 nil，v, ok := m[k] 依然安全（v 为 nil），但若误写成 m[k] 直接解引用，就错了。这类边界得靠经验+工具双重覆盖。
