Go go-cmp nil 切片和空切片为什么比较不相等

在用go-cmp做数据对比的时候，经常碰到nil切片和空切片明明都没有元素，对比结果却返回不相等的情况，核心原因是这两类切片的底层切片头里的指针字段值不一样，go-cmp默认会校验所有字段的内容，自然就识别出了两者的差异。

nil切片没有绑定任何底层数组，它的底层指针字段值为nil；空切片已经初始化了长度和容量都为0的底层数组，指针指向Go runtime预定义的全局空对象地址，切片头的指针字段不匹配，go-cmp开启全字段比对时就会判定两者不相等。

测试里两边都是零个元素，go-cmp 却报不相等，问题通常不是长度，而是 nil 与非 nil 空切片的状态区别。对于普通的同类型切片，默认比较保留这层区别；只有业务确实把二者视为同一种空集合时，才需要显式配置 EquateEmpty。

把失败断言缩成两个零长度切片

先把数据库、网络和业务结构体移开，只比较一个未初始化的 []string 与一个空字面量 []string{}。前者是 nil，后者不是 nil，但长度都是零。不要据此推断 cmp.Equal 也只看长度：它比较的是值的结构和适用规则，不是单纯的元素数量。

如果“没有设置”和“明确设置为空”在当前接口里有不同含义，测试失败恰好是在提醒这项差异。反过来，如果查询没有结果时允许返回这两种表示，则可以在这个测试边界放宽空集合规则。

固定依赖，明确比较策略

本例使用 go-cmp v0.7.0 作为可复现的依赖版本，不把它表述为最新版本。在已经安装 Go 的环境中新建一个独立目录，初始化模块并添加依赖：

mkdir cmp-empty-demo
cd cmp-empty-demo
go mod init example.com/cmp-empty-demo
go get github.com/google/go-cmp@v0.7.0

项目只需要 main.go。这里不是修复生产函数，而是建立一个比较规则演示：同一对值分别使用默认选项和 EquateEmpty。选项改变的是比较语义，不会把原变量从 nil 改成非 nil，也不会修改输入数据。

用一个小程序观察默认与宽松比较

把下面内容保存为 main.go。三组样本分别覆盖状态差异、相同空值和真实元素差异，避免仅凭第一组通过就以为选项忽略了整个切片。

package main

import (
    "fmt"

    "github.com/google/go-cmp/cmp"
    "github.com/google/go-cmp/cmp/cmpopts"
)

func main() {
    var unset []string
    empty := []string{}

    cases := []struct {
        name string
        want []string
        got  []string
    }{
        {"nil-vs-empty", unset, empty},
        {"empty-vs-empty", empty, []string{}},
        {"different-elements", []string{"a"}, []string{"b"}},
    }

    // 只在当前演示里启用空集合等价。
    opts := cmp.Options{cmpopts.EquateEmpty()}
    for _, c := range cases {
        fmt.Printf("%s default=%t relaxed=%t\n",
            c.name,
            cmp.Equal(c.want, c.got),
            cmp.Equal(c.want, c.got, opts...))
    }

    // 比较没有改变原切片的 nil 状态。
    fmt.Printf("unset-nil=%t empty-nil=%t\n", unset == nil, empty == nil)
}

运行入口是 go run .。以下结果是根据该示例和文档规则推导的预期结果，并非本文保存的实测终端输出：

nil-vs-empty default=false relaxed=true
empty-vs-empty default=true relaxed=true
different-elements default=false relaxed=false
unset-nil=true empty-nil=false

预期结果应该怎么读

第一行只放宽零长度集合的表示方式。第二行确认普通空切片原本就能相等。第三行保留 a 与 b 的元素差异，说明 EquateEmpty 不是“所有切片都相等”。最后一行说明比较策略和数据初始化是两回事。

排查实际断言时，可临时记录长度与是否为 nil，不要只打印长度。如果使用带自定义 Equal 方法的类型或其他比较选项，结论还要结合这些规则；本文演示的是普通 []string，未引入自定义 Equal 方法。

接入测试时统一 Equal 和 Diff 选项

确认业务允许空集合等价后，把选项放在这个测试里，并让判断与差异说明使用同一份配置。下面片段接在已有的 got、want 和 t 之后，不是独立可运行文件：

// 当前测试约定：没有结果时，nil 与空集合等价。
opts := cmp.Options{cmpopts.EquateEmpty()}
if !cmp.Equal(want, got, opts...) {
    // 使用同一配置，避免判断和诊断采用两套空值规则。
    t.Errorf("result mismatch (-want +got):\n%s",
        cmp.Diff(want, got, opts...))
}

也可以直接用带同样选项的 cmp.Diff 是否为空字符串作为断言条件。不要硬编码完整 diff 文本作黄金输出；测试关心的应是业务差异，而不是差异文本的排版。

哪些差异仍应保留

EquateEmpty 同时作用于零长度 map 和 slice，不只处理顶层这个切片。若把它直接传给整个结构体比较，其中其他空集合也可能受影响。不能为了让一个字段通过就顺手把整份响应的空值差异都抹掉。

当某个字段用 nil 表示“尚未加载”，非 nil 空集合表示“已加载但无结果”时，应保留默认规则，或另行设计限定范围的比较选项。不要仅靠 len(want) == len(got) 替代元素比较，否则两个长度相同但内容不同的切片也会被误判。

这个最小项目的验收重点是三组结果各自有意义：状态差异可以按契约放宽，已有相等不被破坏，真实元素差异仍被保留。先明确需要验证什么，再决定是否启用 EquateEmpty，而不是看到红色断言就全局加选项。

参考：cmp.Equal 官方文档；EquateEmpty 官方文档。本文据这些规则设计示例，未宣称进行了本地代码运行验证。