Go 的 nil 值判断，千方百计，还是踩坑！

坚持思考，就会很酷

今天奇伢给大家分享一个实际踩坑的一个示例，以为的 nil 并不是 nil。众所周知，Go 编程中 nil 值的判断可谓是随处可见：

v := findSomething()
if v != nil {// do something
}

nil 值究竟是什么？这个在之前的文章也分析过（深度剖析 Go 的 nil ），并且也提到了在 interface 相关赋值的时候有差异。但是在实际的项目开发的时候，由于流程过于复杂，代码量过于多，还是不可避免的踩到坑。什么坑呢？

以为某个 interface 判断应该是 nil ，但其实判断是非 nil 的。其实这个知识点以前也理解过，但是又踩到了，太隐蔽了，所以专门分享一次。

复习 interface 的 nil 知识

它的定义长这样：

type iface struct {tab *itabdata unsafe.Pointer
}
type eface struct {_type *_typedata unsafe.Pointer
}

interface 变量定义是一个 16 个字节的结构体，首 8 字节是类型字段，后 8 字节是数据指针。普通的 interface 是 iface 结构，interface{} 对应的是 eface 结构；
interface 变量新创建的时候是 nil ，则这 16 个字节是全 0 值；
interface 变量的 nil 判断，汇编逻辑是判断首 8 字节是否是 0 值；

踩坑记录

奇伢的踩坑操作很简单，但也还是把我下了一身冷汗。在一个函数里明明返回了 nil 值，但是到了外面判断却是非 nil 。

type Worker interface {Work() error
}type Qstruct struct{}func (q *Qstruct) Work() error {return nil
}// 返回一个 nil 
func findSomething() *Qstruct {return nil
}func main() {// 定义好接口var v Workerv = findSomething()if v != nil {// 走的是这个分支fmt.Printf("v(%v) != nil\n", v)} else {fmt.Printf("v(%v) == nil\n", v)}
}

震惊！findSomething 这个函数返回的明确是 nil，但是 if 判断的分支走的是 != nil 这个分支。当时我确实愣了 10 秒，然后才反应过来。虽然知识点以前知道，但是实际编程还是不免踩坑。

1 深究下这里的原因是啥？

回到 v = findSomething() 这行代码。这个是关键。这个是一个赋值操作，左边是一个接口变量，函数 findSomething 返回的是一个具体类型指针。所以，它一定会把接口变量 iface 前 8 字节设置非零字段的，因为有具体类型呀（无论具体类型是否是 nil 指针）。而判断 interface 是否是 nil 值，则是只根据 iface 的前 8 字节是否是零值判断的。

划重点：具体类型到接口的赋值一定会导致接口非零（不考虑编译不过等问题）。

这个问题的原理就这样简单。

2 那么怎么改呢？

记住一个原则：如果任何地方有判断接口是否为 nil 值的逻辑，那我建议你一定不要写任何有 接口 = 具体类型(nil) 逻辑的代码。如果是 nil 值就直接赋给接口，而不要过具体类型的转换。

所以上面的改动很简单：

// 如果 findSomething 需要返回 nil 值，那么直接返回 nil 的 interface 
func findSomething() Worker {return nil
}

这样，findSomething 需要返回 nil 的时候，则是直接返回 nil 的 interface，这是一个 16 个字节全零的变量。而在外面赋值给 v 的时候，则是 interface 到 interface 的赋值，所以 v = findSomething() 的赋值之后，v 还是全 0 值。

总结

千万要注意。如果 interface 被具体类型变量赋值过，变量的类型会被赋值到首 8 字节。从而导致 interface 非 nil 。无论具体类型变量本身是不是 nil；
如果函数返回具体类型，然后在其他地方又要赋值给接口，那还不如函数直接返回接口类型；
过一遍 interface 的原理，背诵：千万不要写任何可能存在 接口 = 具体类型(nil) 的代码，如果有 nil 值，直接赋给接口吧，不要再过中间商了；
再背一遍；