Go中nil指针错误源于未检查就解引用，需在函数参数、结构体字段、接口断言、map/slice/channel操作前显式校验nil，建立所有权意识和防御性编程习惯。
Go语言中nil指针错误（panic: runtime error: invalid memory address or nil pointer dereference）大多源于未检查指针是否为nil就直接解引用。避免这类错误的关键不是“完全不用指针”，而是建立清晰的所有权意识和显式校验习惯——尤其在函数入参、结构体字段、接口转换、map/slice元素取值等常见场景中。
函数参数传入时主动防御
当函数接受指针类型参数（如 *User、*Config），不能默认它非nil。应在函数入口立即判断，早失败、早提示：
- 用 if p == nil { return fmt.Errorf("user cannot be nil") } 返回错误，而非继续执行
- 若逻辑上该指针必须非nil，可 panic 但需附带明确上下文：if u == nil { panic("NewOrder: user pointer is nil") }
- 避免在多层嵌套调用中传递裸指针而不校验——比如 f1 → f2 → f3，f2 若未校验就传给f3，出错时栈信息难定位
结构体内嵌指针字段要设默认约束
定义含指针字段的结构体时，应通过构造函数或初始化方法控制其状态，而不是放任零值：
- 不要让 User struct { Name *string } 的 Name 字段长期处于“可能nil”又不说明语义的状态
- 推荐用 NewUser(name string) *User 显式初始化，内部确保关键字段非nil；或用 WithName(name string) Option 模式组合构建
- 若字段语义允许为空（如 MiddleName），则访问前必须检查：if u.MiddleName != nil { fmt.Println(*u.MiddleName) }
接口转指针或类型断言前先判空
interface{} 类型变量可能为nil，直接断言成指针会panic：
- 错误写法：u
:= data.(*User); fmt.Println(u.Name) —— data为nil时直接panic
- 正确写法：if u, ok := data.(*User); ok && u != nil { fmt.Println(u.Name) }
- 同理，从 map[string]interface{} 取值后，务必先 assert 再判 nil，不能跳步
map、slice、channel 等引用类型也要小心“空但非nil”
虽然 map、slice、channel 是引用类型，但它们的零值是 nil，对 nil 值做操作会panic：
- var m map[string]int; m["k"] = 1 → panic！需先 make(m) 或判断 if m == nil { m = make(map[string]int) }
- slice 的 len() 和 cap() 对 nil 安全，但 []int(nil)[0] 不安全；用前建议 if len(s) > 0 { ... }
- channel 同理：var ch chan int; close(ch) → panic；发送/接收前可用 if ch != nil 判断（但更推荐初始化后才使用）
基本上就这些。Go 的 nil 不是 bug，是设计的一部分；健壮性不靠侥幸，靠每次解引用前那半秒的条件判断——写得清楚，读得安心，跑得稳当。
:= data.(*User); fmt.Println(u.Name) —— data为nil时直接panic