Go中nil指针访问panic的本质是底层内存访问违规，不可recover；必须在解引用前显式检查，如if p != nil再使用*p或p.Field。
Go 中 nil 指针访问 panic 的本质原因
Go 运行时在解引用 nil 指针时直接触发 panic: runtime error: invalid memory address or nil pointer dereference，这不是可恢复的错误，而是底层内存访问违规。这意味着 if p == nil 判断必须出现在所有 *p、p.Field、p.Method() 之前——没有“事后补救”机制。
struct 字段指针成员的常见误判场景
当结构体含指针字段（如 *string、*User），容易混淆“结构体本身非 nil”和“其字段非 nil”。例如：
type Config struct {
Timeout *int
Name *string
}
cfg := &Config{} // cfg != nil，但 cfg.Timeout == nil，cfg.Name == nil
fmt.Println(*cfg.Timeout) // panic!
这类问题高频出现在 JSON 反序列化或配置初始化中，尤其当字段未显式赋值时默认为 nil。
- JSON 解析时缺失字段 → 对应指针字段保持
nil - 使用
new(Config)或字面量&Config{}→ 所有指针字段初始化为nil - 方法接收者为指针类型，但调用方传入
nil→ 接收者为nil，内部访问字段仍 panic
安全解引用的三种实操模式
避免 panic 的核心是「提前守门」，而非「兜底 recover」。recover 对 nil panic 无效，且破坏错误传播路径。
立即学习“go语言免费学习笔记（深入）”；
模式一：显式 nil 检查 + 短路逻辑
if cfg.Timeout != nil {
fmt.Println("timeout:", *cfg.Timeout)
} else {
fmt.Println("timeout not set")
}
模式二：封装安全访问函数（适合重复场景）
func SafeDerefInt(p *int, def int) int {
if p == nil {
return def
}
return *p
}
// 使用
timeout := SafeDerefInt(cfg.Timeout, 30)
模式三：接口抽象 + 零值友好的方法
- 定义接口（如
Timeouter）并让 struct 实现，内部处理nil分支 - 避免暴露裸指针字段，改为提供
Timeout() int方法，内部返回默认值
map/slice/channel 的 nil 判断与指针无关但常被混淆
新手常把 map、slice、channel 的 nil 误当作指针问题，其实它们是引用类型，但底层描述符为 nil 时行为不同：
-
nil map：读写都 panic（assignment to entry in nil map） -
nil slice：读不 panic（长度为 0），写（如append）合法 -
nil channel：发送/接收阻塞（永久），select中跳过
这些类型是否 nil 应用 == nil 判断，但和指针安全检查是正交问题——别因为写了 if m != nil 就以为指针也安全了。
真正容易漏掉的是嵌套场景：比如 map[string]*User 中取到的 *User 仍是可能为 nil 的指针，必须二次检查。
