17370845950

Go中指针零值为nil，解引用前必须判空，否则panic；接口nil判断需注意类型与值双空；结构体指针字段需分层判空，跨边界场景尤需警惕。

Go 中指针的零值就是 nil，不是“未定义”，也不是“空地址”，而是语言明确定义的、可安全比较的零值。解引用前不判断 ptr == nil，程序必然 panic。

为什么不能直接解引用未判空的指针

Go 的指针是显式类型，*T 类型变量未初始化或显式赋为 nil 时，其值就是 nil。对它执行 *ptr 操作会触发运行时 panic：invalid memory address or nil pointer dereference。

• 函数返回指针（如 json.Unmarshal 返回 *T）可能为 nil，尤其在解析失败或字段缺失时
• 结构体中嵌套指针字段（如 type User struct{ Profile *Profile }），即使 user 非 nil，user.Profile 仍可能为 nil
• 手动 new 或 & 操作前忘记检查上游来源是否有效，比如从 map 取值后未判空就取指针字段

如何安全判断指针是否为 nil

用 == nil 是最直接、最推荐的方式。Go 规范保证所有指针类型都支持与 nil 比较，且该操作常量时间、无副作用。

• ✅ 正确：if ptr != nil { name := *ptr }
• ❌ 错误：if ptr != (*T)(nil) { ... } —— 不必要，且易出错
• ⚠️ 注意：nil 不能和非指针类型比较，比如 int、string、time.Time 都不能和 nil 比（编译报错）
• ⚠️ 特别注意：接口类型也叫 nil，但它的 nil 判断逻辑完全不同——不要把 io.Writer 接口变量当成普通指针来判空

常见误判场景：接口里的指针是 nil，但接口本身不是 nil

这是 Go 中最典型的 nil 陷阱。接口变量由两部分组成：动态类型（type）和动态值（value）。只有两者同时为空，接口才整体为 nil。

• ❌ 错误假设：var w io.Writer = (*bytes.Buffer)(nil); if w == nil { ... } → 实际上 w != nil，因为 type 是 *bytes.Buffer
• ✅ 正确做法：先类型断言，再判断底层指针：if b, ok := w.(*bytes.Buffer); ok && b == nil { ... }
• ? 典型案例：函数返回 error（接口类型），你不能靠 err == nil 就认为底层没发生错误；但如果函数内部返回了 fmt.Errorf("...")，那 err 就是非 nil 接口，没问题；真正危险的是返回了 (*MyError)(nil) 这类构造

结构体字段为指针时，零值判断要分层

结构体本身是值类型，零值是各字段零值的组合；其中指针字段的零值就是 nil，但它不影响结构体变量本身的可访问性。

• ✅ 安全写法：if user != nil && user.Profile != nil { name := user.Profile.Name }
• ⚠️ 千万别省略中间判空：结构体非 nil ≠ 字段非 nil；user 是局部变量？它根本不可能是 nil（除非是 *User）
• ? 衍生技巧：若需批量判断多个指针字段是否全被设置，可用 reflect + IsNil()，但更推荐业务层显式校验，避免反射开销和可读性损失

真正难的不是“怎么写 if ptr == nil”，而是意识到哪些地方 *可能* 出现 nil——尤其是跨包调用、JSON 解析、数据库扫描、HTTP 响应反序列化这些边界场景。一旦漏掉一层判空，panic 就在下一行等着你。