Go中对nil指针解引用必然panic，必须在使用前显式判空；嵌套指针需逐层检查或封装辅助函数；接口断言后仍需验证底层指针非nil；优先用值类型+有效性标记替代裸指针。
Go 中对 nil 指针解引用一定会 panic，没有例外，也没有静默失败——只要写 *p 或 p.field 且 p == nil，运行时立刻崩溃，错误信息是 panic: runtime error: invalid memory address or nil pointer dereference。这不是“可能出错”，而是确定性中断，必须靠主动检查拦截。
函数参数为 *T 时必须首行判空
外部调用方传入的指针不可信，尤其是来自 JSON 反序列化、gRPC、HTTP 请求体或 map 查找的结果。文档说“非空”也不可靠，json.Unmarshal 遇到缺失字段或 null 就留 nil。
- 正确姿势：函数一进来就写
if p == nil { return }或return errors.New("xxx cannot be nil") - 错误写法：
if p != nil && *p == "admin"——p == nil时短路求值救不了你，*p已先 panic - 别在多层嵌套中漏检：比如
f1→f2→f3，若f2不校验直接传给f3，出错栈里看不到f2的上下文，排查困难
结构体指针字段访问前逐层判空
嵌套指针链（如 u.Profile.Address.City）是空引用高发区。任意一环为 nil，下一行就崩。Go 不提供安全导航语法（如 Kotlin 的 ?.），只能手动控制。
- 不推荐连写：
if u != nil && u.Profile != nil && u.Profile.Address != nil { ... }—— 冗长且易漏 - 推荐封装辅助函数：
func cityName(u *User) string { if u == nil || u.Profile == nil || u.Profile.Address == nil { return "" }; return u.Profile.Address.City } - 更彻底的解法：把深层指针字段改为值类型（如
Address Address而非Address *Address），或用内嵌结构体降低间接层级
接口变量断言后仍需判指针是否为 nil
接口变量本身为 nil 和它内部装的值为 nil 是两回事。常见陷阱是 interface{} 接收了一个 *string，而该指针恰为 nil，此时接口不为 nil，但断言后直接解引用就 panic。
- 错误写法：
var i interface{} = (*string)(nil); s := i.(*string); fmt.Println(*s)—— 第三行 panic - 正确顺序：先类型断言 +
ok检查，再判断底层指针是否为nil：if s, ok := i.(*string); ok && s != nil { fmt.Println(*s) } - 从
map[string]interface{}取值也一样：必须v, ok := m["key"]后再断言，不能跳步；且m本身也得先确认非nil，否则m["key"]这一步就 panic
避免裸指针字段，优先用值类型 + 显式有效性标记
*string、*int 这类字段常被误用于表达“可选”，结果引入大量 nil 风险。其实 Go 的零值（""、0、false）已足够表达“未设置”，除非业务上真要区分“零值”和“未提供”。
- 简单场景：用
string字段 + 单独的HasName bool标志位 - 标准做法：用第三方库如
github.com/guregu/null的null.String，内部含Valid字段，String()方法自动处理!Valid情况 - 自定义类型示例：
type OptionalString struct { Value string; Valid bool }，封装String()和IsSet()方法，比裸指针语义清晰、调用安全
最易被忽略的是：map、slice、channel 的零值也是 nil，它们不是指针类型，但行为类似——对 nil map 赋值、对 nil channel 发送、对 nil slice 索引都会 panic。它们和指针的 nil 判空方式一致（m == nil），但语义不同，混淆这两类是高频翻车点。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
