Go 语言类型可比性

发表于 3年以前 | 总阅读数：408 次

前段时间，一位读者私信了我一个 Go 代码例子，并问我这是不是一个 bug。我觉得蛮有意思的，故整理出了本文的分享内容。

在讨论代码之前，读者需要有一些前置知识。

Go 可比较类型

在 Go 中，数据类型可以被分为两类，可比较与不可比较。两者区分非常简单：类型是否可以使用运算符 == 和 != 进行比较。

那哪些类型是可比较的呢？

Boolean（布尔值）、Integer（整型）、Floating-point（浮点数）、Complex（复数）、String（字符）这些类型是毫无疑问可以比较的。
Poniter (指针) 可以比较：如果两个指针指向同一个变量，或者两个指针类型相同且值都为 nil，则它们相等。注意，指向不同的零大小变量的指针可能相等，也可能不相等。
Channel （通道）具有可比性：如果两个通道值是由同一个 make 调用创建的，则它们相等。

 c1 := make(chan int, 2)
 c2 := make(chan int, 2)
 c3 := c1

 fmt.Println(c3 == c1) // true
 fmt.Println(c2 == c1) // false

Interface （接口值）具有可比性：如果两个接口值具有相同的动态类型和相等的动态值，则它们相等。
当类型 X 的值具有可比性且 X 实现 T 时，非接口类型 X 的值 x 和接口类型 T 的值 t 具有可比性。如果 t 的动态类型与 X 相同且 t 的动态值等于 x，则它们相等。
如果所有字段都具有可比性，则 struct （结构体值）具有可比性：如果它们对应的非空字段相等，则两个结构体值相等。
如果 array（数组）元素类型的值是可比较的，则数组值是可比较的：如果它们对应的元素相等，则两个数组值相等。

哪些类型是不可比较的？

slice、map、function 这些是不可以比较的，但是也有特殊情况，那就是当他们值是 nil 时，可以与 nil 进行比较。

动态类型

在上文接口可比性中，我们提到了动态类型与动态值，这里需要介绍一下。

常规变量（非接口）的类型是由声明所定义，这是静态类型，例如 var x int。

接口类型的变量有一个独特的动态类型，它是运行时存储在变量中的值的实际类型。动态类型在执行过程中可能会有所不同，但始终可以分配给接口变量一个静态类型。

例如

var someVariable interface{} = 101

someVariable 变量的静态类型是 interface{}，但是它的动态类型是 int，并且很可能在之后发生变化。

 var someVariable interface{} = 101
 someVariable = 'Gopher'

如上， someVariable 变量的动态类型从 int 变为了 string。

代码场景示例

我们为当前业务所需的数据模型定义一个结构体 Data，它包含两个字段：一个 string 类型的 UUID 和 interface{} 类型的 Content。

type Data struct {
 UUID    string
 Content interface{}
}

根据上文介绍， string 类型和 interface 是可比较类型，那么两个 Data 类型的数据，我们可以通过 == 操作符进行比较。

var x, y Data
 x = Data{
  UUID:    "856f5555806443e98b7ed04c5a9d6a9a",
  Content: 1,
 }
 y = Data{
  UUID:    "745dee7719304991862e6985ea9c02a9",
  Content: 2,
 }
 fmt.Println(x == y)

但是，如果在 Content 中的动态类型是 map 会怎样？

 var m, n Data
 m = Data{
  UUID:    "9584dba3fe26418d86252d71a5d78049",
  Content: map[int]string{1: "GO", 2: "Python"},
 }
 n = Data{
  UUID:    "9584dba3fe26418d86252d71a5d78049",
  Content: map[int]string{1: "GO", 2: "Python"},
 }
 fmt.Println(m == n)

此时，我们程序编译通过，但会发生运行时错误。

panic: runtime error: comparing uncomparable type map[int]string

那针对这种需求：即对于不可比较类型，因为不能使用比较操作符 ==，但我们想要比较它们包含的值是否相等时，应该怎么办。

此时我们可以采用 reflect.DeepEqual 函数进行比较，即将上述的 m==n 替换

fmt.Println(reflect.DeepEqual(m,n)) // true

我们得出结论：如果我们的变量中包含不可比较类型，或者 interface 类型（它的动态类型可能存在不可比较的情况），那么我们直接运用比较运算符 == ，会引发程序错误。此时应该选用 reflect.DeepEqual 函数（当然也有特殊情况，例如 []byte，可以通过 bytes. Equal 函数进行比较）。

Bug 代码？

好，铺垫了这么久，终于可以展示读者给我的代码了。

 var x, y Data
 x = Data{
  UUID:    "856f5555806443e98b7ed04c5a9d6a9a",
  Content: 1,
 }
 bytes, _ := json.Marshal(x)
 _ = json.Unmarshal(bytes, &y)
 fmt.Println(x)  // {856f5555806443e98b7ed04c5a9d6a9a 1}
 fmt.Println(y)  // {856f5555806443e98b7ed04c5a9d6a9a 1}
 fmt.Println(reflect.DeepEqual(x, y)) // false

对于同一个原始数据，经过 json 的 Marshal 和 Unmarshal 过程后，竟然不相等了？难道有 bug？

不慌，这种时候，我们直接上调试看看。

debug

原来此 1 非彼 1，Content 字段的数据类型由 int 转换为了 float64 。而在接口中，其动态类型不一致时，它的比较是不相等的。

经过排查，发现问题就出在 Unmarshal 函数上：如果要将 Json 对象 Unmarshal 为接口值，那么它的类型转换规则如下

Unmarshal

可以看到，数值型的 json 解析操作统一为了 float64。

因此，如果我们将 Content: 1 改为 Content: 1.0 ，那么它 reflect.DeepEqual(x, y) 的值将是 true。

增强型 DeepEqual 函数

针对 json 解析的这种类型改变特性，我们可以基于 reflect.DeepEqual 函数进行改造适配。

func DeepEqual(v1, v2 interface{}) bool {
 if reflect.DeepEqual(v1, v2) {
  return true
 }
 bytesA, _ := json.Marshal(v1)
 bytesB, _ := json.Marshal(v2)
 return bytes.Equal(bytesA, bytesB)
}

当我们使用增强后的函数来运行上述的 “bug” 例子

 var x, y Data
 x = Data{
  UUID:    "856f5555806443e98b7ed04c5a9d6a9a",
  Content: 1,
 }
 b, _ := json.Marshal(x)
 _ = json.Unmarshal(b, &y)
 fmt.Println(DeepEqual(x, y)) // true

此时，结果符合我们的预期。