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 是静默发生的，测试若没覆盖缺失字段场景，上线后才暴露。