Go语言如何判断一个指针是否为空_Golang nil判断规范

go中判断指针是否为nil直接用p == nil，切片、map、channel、func、interface等同理；但Interface{}的nil需类型和值均为零，嵌套指针须逐层判空。

Go里怎么判断指针变量是否为nil

直接用 == nil 就行，这是最安全、最标准的做法。Go 的指针类型（包括自定义结构体指针、切片、map、channel、func、interface）在未初始化时默认值就是 nil，且可直接与 nil 比较。

常见错误是误以为要解引用再判断，比如写 *p == nil —— 这会 panic，因为 p 本身是 nil 时无法解引用。

• var p *int → p == nil 正确；*p == nil 错误（panic）
• var s []String → s == nil 正确；len(s) == 0 只能说明长度为 0，但 s 可能是非 nil 空切片
• var m map[string]int → m == nil 正确；len(m) == 0 同样无法区分 nil map 和空 map

interface{} 类型的 nil 判断为什么容易出错

interface{} 的 nil 判断不是看底层值，而是看整个接口的动态类型和动态值是否都为零。即使你传了一个 *int 的 nil 指针进去，该 interface 也不等于 nil。

典型陷阱：

立即学习“go语言免费学习笔记（深入）”；

func foo() *int { return nil } var i interface{} = foo() fmt.Println(i == nil) // false！

原因：i 的动态类型是 *int，动态值是 nil，但类型非空 → 整个 interface 非 nil。

• 判断 interface 是否为 nil，必须用 i == nil（仅当类型和值都未设置时才成立）
• 若想检查它是否“包装了一个 nil 指针”，需先类型断言：if p, ok := i.(*int); ok && p == nil
• 不要依赖 fmt.printf("%v", i) 输出来判断，它可能显示 但 i != nil

Struct 成员指针字段的 nil 判断要注意什么

结构体字段如果是指针类型（如 *User），其初始值就是 nil，但必须显式访问该字段才能判断，不能靠结构体整体是否为 nil 来推断。

例如：

type Order struct {     Customer *User } var o Order fmt.Println(o == nil)        // 编译错误：o 是值类型，不能和 nil 比较 fmt.Println(o.Customer == nil) // true，正确

• 结构体变量本身永远不为 nil（除非是指针类型 *Order）
• 嵌套指针字段（如 o.Customer.Address.Street）必须逐层判空，否则易 panic
• 推荐用短路逻辑：o.Customer != nil && o.Customer.Address != nil && o.Customer.Address.Street != nil

nil 判断在 defer、Error 处理和 channel 场景下的特殊表现

某些类型虽底层是指针（如 error、http.ResponseWriter），但它们是接口类型，遵循 interface 的 nil 规则；channel 和 func 类型也类似。

• err != nil 是标准写法，但注意：自定义 error 实现若返回了非 nil 接口但内部值为空，仍算非 nil
• var ch chan int → ch == nil 正确；向 nil channel 发送或接收会永久阻塞，可用于条件等待
• var f func() → f == nil 正确；调用 f() 前必须判空，否则 panic
• defer 中使用指针时，如果指针在 defer 前已置为 nil，defer 仍会执行，但解引用会 panic —— 所以 defer 内部也要判空

实际写代码时，最容易漏掉的是 interface{} 包装后的 nil 语义变化，以及嵌套指针的逐层判空。这两处不加防护，上线后 panic 很难复现。