Go中nil指针解引用会直接panic，错误信息为“invalid memory address or nil pointer dereference”，常见于未检查nil就解引用、访问字段或调用方法；*T方法可在nil上调用但需避免访问字段；*map/*slice/*channel需双重判空；JSON反序列化*T字段缺失时静默置nil，易引发后续panic。
Go 中 nil 指针解引用会直接 panic
Go 不像 Java 那样抛出 NullPointerException，而是直接触发运行时 panic，错误信息通常是 panic: runtime error: invalid memory address or nil pointer dereference。只要对 nil 指针做解引用（*p）、调用其方法、访问其字段，就会立即崩溃——没有“空安全”兜底机制。
常见触发点包括：
- 函数返回
nil *T后未检查就直接*p或p.Field - 结构体字段是
*T类型，初始化遗漏导致为nil，后续访问未判空 - 使用
new(T)或&T{}本意是构造值，但误写成var p *T且未赋值
func(*T) 方法接收者在 nil 时是否安全？
Go 允许为 *T 类型定义方法，且该方法可在 nil 指针上调用——但仅限于方法体内不访问 receiver 的字段或方法。一旦出现 r.field 或 r.Method()，就会 panic。
典型安全场景是“零值有意义”的操作，比如：
立即学习“go语言免费学习笔记（深入）”；
type Counter struct {
count int
}
func (c *Counter) Inc() {
if c == nil {
return // 显式容忍 nil
}
c.count++
}
func (c *Counter) String() string {
if c == nil {
return ""
}
return fmt.Sprintf("Counter(%d)", c.count)
}
若省略 c == nil 判断，Inc() 中的 c.count++ 就会 panic。
map / slice / channel 的指针包装容易误判非空
开发者常把 map[string]int 包一层指针：*map[string]int，以为“有地址就安全”，其实不然。该指针本身可能为 nil，而它指向的 map 也可能为 nil——两层都需检查。
例如：
var m *map[string]int
// m 是 nil 指针；即使 m != nil，*m 仍可能是 nil map
if m != nil && *m != nil {
(*m)["key"] = 42 // 安全写入
}
同理适用于 *[]int 和 *chan int。错误模式是只检查外层指针，忽略内层值本身的 nil 性。
JSON 反序列化时 *T 字段默认为 nil 不报错
json.Unmarshal 对结构体中类型为 *T 的字段，若 JSON 中对应 key 缺失或为 null，会保持该字段为 nil，且不报错。这极易埋下隐患：
type User struct {
Name *string `json:"name"`
Age *int `json:"age"`
}
var u User
json.Unmarshal([]byte(`{"name": "Alice"}`), &u)
// u.Age == nil —— 后续若直接 *u.Age 就 panic
解决方式有二：
- 反序列化后统一校验关键字段非 nil（适合业务强约束）
- 改用值类型（如
int）+ 自定义UnmarshalJSON处理缺失逻辑
最易被忽略的是：这种 nil 是静默发生的，测试若没覆盖缺失字段场景，上线后才暴露。
