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 *itab
data unsafe.Pointer
}
type eface struct {
_type *_type
data 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 Worker
v = 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 值，直接赋给接口吧，不要再过中间商了； - 再背一遍；
