17370845950

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：

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？这些必须在设计阶段就明确，而不是靠补丁式加判断。