Go中nil仅适用于指针、切片、map、channel、func、interface六类引用类型；非引用类型零值非nil且不可与nil比较，误判会导致编译错误或运行时panic。
Go 中 nil 只能赋值给指针、切片、map、channel、func、interface 类型
很多初学者误以为 var x int 的零值是 nil，其实不是——int 的零值是 0，string 是 ""，bool 是 false。只有上述六类引用类型才可能为 nil。对非引用类型做 == nil 判断会编译报错：invalid operation: x == nil (mismatched types int and nil)。
常见错误场景：
- 把结构体字段声明为
*string但没初始化，后续直接解引用*field - 用
make([]T, 0)创建空切片是安全的，但var s []T声明后为nil，调用len(s)没问题，但s[0]或append(s, x)在某些旧版本 Go 中可能触发 panic（实际现代 Go 中append对nil切片是安全的，但逻辑上仍建议显式初始化）
判断指针是否为 nil 前必须确认其类型支持
不能对任意变量写 if x == nil。例如：
type User struct {
Name *string
Age int
}
var u User
if u.Name == nil { // ✅ 合法：*string 是指针类型
fmt.Println("name not set")
}
if u.Age == nil { // ❌ 编译失败：cannot compare int == nil
}
更隐蔽的问题出现在 interface 类型：一个 interface 变量为 nil，仅当其底层 concrete value 和 concrete type 都为 nil 时，该 interface 才是 nil。若你传入一个 *T 并赋值给 interface{}，即使该指针本身是 nil，interface 也不为 nil：
立即学习“go语言免费学习笔记（深入）”；
var p *string = nil
var i interface{} = p
fmt.Println(i == nil) // false！因为 i 的 type 是 *string，value 是 nil，但 interface 本身非 nil
fmt.Println(p == nil) // true
所以，对 interface 做 nil 判断要格外小心，尤其在函数参数或返回值中接收 interface{} 或自定义接口时。
避免 nil 指针解引用的三个实操习惯
核心原则：解引用前必检查，但检查方式要匹配类型和上下文。
-
对函数返回的指针，优先用多值返回 + error 判断：比如
json.Unmarshal不返回指针，但你自己封装的解析函数若返回*User，应改为(*User, error)，让调用方自然处理失败路径 -
结构体初始化统一用构造函数，而非字面量直赋：避免
User{Name: nil}这种易出错写法，改用NewUser(name string)内部做非空校验或默认填充 -
对 map / slice / channel，用
len(x) == 0或x != nil区分语义：例如 map 为nil时遍历会 panic，应先判if m != nil；而切片为nil时len返回 0，可直接用，但若需取元素则必须先确保非nil或已 make
测试 nil 场景不能只靠手动构造，要用 go vet 和 staticcheck
Go 自带 go vet 能捕获部分明显问题，比如对未初始化指针的无条件解引用（虽不总能发现）。更推荐接入 staticcheck（go install honnef.co/go/tools/cmd/staticcheck@latest），它能识别：
-
if x != nil { return *x }—— 但x实际不可能为nil（冗余检查） -
return *p出现在p可能为nil的路径上（高危） - 函数参数声明为
*T却在入口未做nil检查就直接解引用
CI 中加入 staticcheck ./... 可提前拦截多数运行时 panic: runtime error: invalid memory address or nil pointer dereference。
最常被忽略的是：nil 判断本身有成本，但比 panic 恢复廉价得多；而真正的难点不在“怎么写 if”，在于厘清每个指针变量的生命周期边界——它由谁分配？是否可能未初始化？是否可能被提前置为 nil？这些必须在设计阶段就明确，而不是靠补丁式加判断。
