本文是Go比較有名的一個坑，在以前面試的時候也被問過，為什么想起來寫這個？
因為我們線上就真實出現過這個坑,寫給不了解的人在使用 if err != nil 的時候提高警惕。
Go語言的interface{}在使用過程中有一個特別坑的特性，當你比較一個interface{}類型的值是否是nil的時候，這是需要特別注意避免的問題。
先來看看一個demo：
package main
import "fmt"
type ErrorImpl struct{}
func (e *ErrorImpl) Error() string {
return ""
}
var ei *ErrorImpl
var e error
func ErrorImplFun() error {
return ei
}
func main() {
f := ErrorImplFun()
fmt.Println(f == nil)
}
輸出：
false
為什么不是true?
想要理解這個問題，首先需要理解interface{}變量的本質。在Go語言中，一個interface{}類型的變量包含了2個指針，一個指針指向值的在編譯時確定的類型，另外一個指針指向實際的值。
// InterfaceStructure 定義了一個interface{}的內部結構
type InterfaceStructure struct {
pt uintptr // 到值類型的指針
pv uintptr // 到值內容的指針
}
// asInterfaceStructure 將一個interface{}轉換為InterfaceStructure
func asInterfaceStructure(i interface{}) InterfaceStructure {
return *(*InterfaceStructure)(unsafe.Pointer(i))
}
func main() {
var i1, i2 interface{}
var v1 int = 23
var v2 int = 23
i1 = v1
i2 = v2
fmt.Printf("sizeof interface{} = %d\n", unsafe.Sizeof(i1))
fmt.Printf("i1 %v %+v\n", i1, asInterfaceStructure(i1))
fmt.Printf("i2 %v %+v\n", i2, asInterfaceStructure(i2))
var nilInterface interface{}
var str *string
fmt.Printf("nil interface = %+v\n", asInterfaceStructure(nilInterface))
fmt.Printf("nil string = %+v\n", asInterfaceStructure(str))
fmt.Printf("nil = %+v\n", asInterfaceStructure(nil))
}
輸出：
sizeof interface{} = 16
i1 23 {pt:4812032 pv:825741246928}
i2 23 {pt:4812032 pv:825741246936}
nil interface = {pt:0 pv:0}
nil string = {pt:4802400 pv:0}
nil = {pt:0 pv:0}
當我們將一個具體類型的值賦值給一個interface{}類型的變量的時候，就同時把類型和值都賦值給了interface{}里的兩個指針。如果這個具體類型的值是nil的話，interface{}變量依然會存儲對應的類型指針和值指針。
如何解決？
方法一
返回的結果進行非nil檢查，然后再賦值給interface{}變量
type ErrorImpl struct{}
func (e *ErrorImpl) Error() string {
return ""
}
var ei *ErrorImpl
var e error
func ErrorImplFun() error {
if ei == nil {
return nil
}
return ei
}
func main() {
f := ErrorImplFun()
fmt.Println(f == nil)
}
輸出：
true
方法二
返回具體實現的類型而不是interface{}
package main
import "fmt"
type ErrorImpl struct{}
func (e *ErrorImpl) Error() string {
return ""
}
var ei *ErrorImpl
var e error
func ErrorImplFun() *ErrorImpl {
return ei
}
func main() {
f := ErrorImplFun()
fmt.Println(f == nil)
}
輸出：
true
解決由于第三方包帶來的坑
由于有的error是第三方包返回的，又自己不想改第三方包，只好接收處理的時候想辦法。
方法一
利用interface{}原理
is:=*(*InterfaceStructure)(unsafe.Pointer(i))
if is.pt==0 is.pv==0 {
//is nil do something
}
將底層指向值和指向值的類型的指針打印出來如果都是0，表示是nil
方法二
利用斷言,斷言出來具體類型再判斷非空
type ErrorImpl struct{}
func (e ErrorImpl) Error() string {
return "demo"
}
var ei *ErrorImpl
var e error
func ErrorImplFun() error {
//ei = ErrorImpl{}
return ei
}
func main() {
f := ErrorImplFun()
//當然error實現類型較多的話使用
//switch case方式斷言更清晰
res, ok := f.(*ErrorImpl)
fmt.Printf("ok:%v,f:%v,res:%v",
ok, f == nil, res == nil)
}
輸出：
ok:true,f:false,res:true
方法三
利用反射
type ErrorImpl struct{}
func (e ErrorImpl) Error() string {
return "demo"
}
var ei *ErrorImpl
var e error
func ErrorImplFun() error {
//ei = ErrorImpl{}
return ei
}
func main() {
f := ErrorImplFun()
rv := reflect.ValueOf(f)
fmt.Printf("%v", rv.IsNil())
}
輸出：
true
注意⚠：
斷言和反射性能不是特別好，如果不得已再使用，控制使用有助于提升程序性能。
由于函數接收類型導致的panic：
type ErrorImpl struct{}
func (e ErrorImpl) Error() string {
return "demo"
}
var ei *ErrorImpl
var e error
func ErrorImplFun() error {
return ei
}
func main() {
f := ErrorImplFun()
fmt.Printf(f.Error())
}
輸出：
panic: value method main.ErrorImpl.Error called using nil *ErrorImpl pointer
解決：
func (e *ErrorImpl) Error() string {
return "demo"
}
輸出：
demo
可以發現將接收類型變成指針類型就可以了。
以上就是 nil 相關的坑，希望大家可以牢記，如果 ”幸運“ 的遇到了，可以想到這些可能性。
補充：go 語言 interface{} 的易錯點
如果說 goroutine 和 channel 是 go 語言并發的兩大基石，那 interface 就是 go 語言類型抽象的關鍵。
在實際項目中，幾乎所有的數據結構最底層都是接口類型。
說起 C++ 語言，我們立即能想到是三個名詞：封裝、繼承、多態。go 語言雖然沒有嚴格意義上的對象，但通過 interface，可以說是實現了多態性。（由以組合結構體實現了封裝、繼承的特性）
package main
type animal interface {
Move()
}
type bird struct{}
func (self *bird) Move() {
println("bird move")
}
type beast struct{}
func (self *beast) Move() {
println("beast move")
}
func animalMove(v animal) {
v.Move()
}
func main() {
var a *bird
var b *beast
animalMove(a) // bird move
animalMove(b) // beast move
}
go 語言中支持將 method、struct、struct 中成員定義為 interface 類型，使用 struct 舉一個簡單的栗子
使用 go 語言的 interface 特性，就能實現多態性，進行泛型編程。
二，interface 原理
如果沒有充分了解 interface 的本質，就直接使用，那最終肯定會踩到很深的坑，要用就先要了解，先來看看 interface 源碼
type eface struct {
_type *_type
data unsafe.Pointer
}
type _type struct {
size uintptr // type size
ptrdata uintptr // size of memory prefix holding all pointers
hash uint32 // hash of type; avoids computation in hash tables
tflag tflag // extra type information flags
align uint8 // alignment of variable with this type
fieldalign uint8 // alignment of struct field with this type
kind uint8 // enumeration for C
alg *typeAlg // algorithm table
gcdata *byte // garbage collection data
str nameOff // string form
ptrToThis typeOff // type for pointer to this type, may be zero
}
可以看到 interface 變量之所以可以接收任何類型變量，是因為其本質是一個對象，并記錄其類型和數據塊的指針。（其實 interface 的源碼還包含函數結構和內存分布，由于不是本文重點，有興趣的同學可以自行了解）
三，interface 判空的坑
對于一個空對象，我們往往通過 if v == nil 的條件語句判斷其是否為空，但在代碼中充斥著 interface 類型的情況下，很多時候判空都并不是我們想要的結果（其實了解或聰明的同學從上述 interface 的本質是對象已經知道我想要說的是什么）
package main
type animal interface {
Move()
}
type bird struct{}
func (self *bird) Move() {
println("bird move")
}
type beast struct{}
func (self *beast) Move() {
println("beast move")
}
func animalMove(v animal) {
if v == nil {
println("nil animal")
}
v.Move()
}
func main() {
var a *bird // nil
var b *beast // nil
animalMove(a) // bird move
animalMove(b) // beast move
}
還是剛才的栗子，其實在 go 語言中 var a *bird 這種寫法，a 只是聲明了其類型，但并沒有申請一塊空間，所以這時候 a 本質還是指向空指針，但我們在 aminalMove 函數進行判空是失敗的，并且下面的 v.Move() 的調用也是成功的，本質的原因就是因為 interface 是一個對象，在進行函數調用的時候，就會將 bird 類型的空指針進行隱式轉換，轉換成實例的 interface animal 對象，所以這時候 v 其實并不是空，而是其 data 變量指向了空。
這時候看著執行都正常，那什么情況下坑才會絆倒我們呢？只需要加一段代碼
package main
type animal interface {
Move()
}
type bird struct {
name string
}
func (self *bird) Move() {
println("bird move %s", self.name) // panic
}
type beast struct {
name string
}
func (self *beast) Move() {
println("beast move %s", self.name) // panic
}
func animalMove(v animal) {
if v == nil {
println("nil animal")
}
v.Move()
}
func main() {
var a *bird // nil
var b *beast // nil
animalMove(a) // panic
animalMove(b) // panic
}
在代碼中，我們給派生類添加 name 變量，并在函數的實現中進行調用，就會發生 panic，這時候的 self 其實是 nil 指針。所以這里坑就出來了。
有些人覺得這類錯誤謹慎一些還是可以避免的，那是因為我們是正向思維去代入接口，但如果反向編程就容易造成很難發現的 bug
package main
type animal interface {
Move()
}
type bird struct {
name string
}
func (self *bird) Move() {
println("bird move %s", self.name)
}
type beast struct {
name string
}
func (self *beast) Move() {
println("beast move %s", self.name)
}
func animalMove(v animal) {
if v == nil {
println("nil animal")
}
v.Move()
}
func getBirdAnimal(name string) *bird {
if name != "" {
return bird{name: name}
}
return nil
}
func main() {
var a animal
var b animal
a = getBirdAnimal("big bird")
b = getBirdAnimal("") // return interface{data:nil}
animalMove(a) // bird move big bird
animalMove(b) // panic
}
這里我們看到通過函數返回實例類型指針，當返回 nil 時，因為接收的變量為接口類型，所以進行了隱性轉換再次導致了 panic（這類反向轉換很難發現）。
那我們如何處理上述這類問題呢。我這邊整理了三個點
1，充分了解 interface 原理，使用過程中需要謹慎小心
2，謹慎使用泛型編程，接收變量使用接口類型，也需要保證接口返回為接口類型，而不應該是實例類型
3，判空是使用反射 typeOf 和 valueOf 轉換成實例對象后再進行判空
您可能感興趣的文章:- Golang中interface{}轉為數組的操作
- 淺談Golang 嵌套 interface 的賦值問題
- Golang 實現interface類型轉string類型
- 解決golang 反射interface{}做零值判斷的一個重大坑
- golang interface判斷為空nil的實現代碼
- 詳解Golang語言中的interface
- 使用go的interface案例實現多態范式操作
- go 類型轉換方式(interface 類型的轉換)
