Go DeepEqual 比较 nil 切片和空切片为什么不相等

这是 Go 里很容易被误判的一组结果：var a []int 和 b := []int{} 的 len 都是 0，遍历结果也一样，但 reflect.DeepEqual(a, b) 仍然是 false。原因不是 DeepEqual 失效，而是它把切片的 nil 状态也纳入了深度相等判断。

如果业务要求“状态也相同”，继续使用 reflect.DeepEqual；如果只关心元素序列，优先使用 slices.Equal，或在边界处先把结果规范化。不要用 len 相同就推断两个切片完全相等。

先看一个最小例子：长度相同不代表状态相同

下面四个判断放在一起，能把问题的边界看清楚。make([]int, 0) 和空字面量创建的是非 nil 空切片；未初始化的切片变量才是 nil。

package main

import (
	"fmt"
	"reflect"
)

func main() {
	var nilItems []int       // 未初始化切片，值为 nil
	emptyItems := []int{}    // 已初始化，但没有元素
	madeItems := make([]int, 0) // 长度为 0 的非 nil 切片

	fmt.Println(len(nilItems), len(emptyItems))
	fmt.Println(nilItems == nil, emptyItems == nil)
	fmt.Println(reflect.DeepEqual(nilItems, emptyItems))
	fmt.Println(reflect.DeepEqual(emptyItems, madeItems))
}

输出重点不是两个长度都为 0，而是第二行：true false。切片不能直接用 == 与另一个切片比较，只能和 nil 比较；这正好让我们观察到它是否带有底层切片值。Go 规范也把未初始化切片的值定义为 nil，而初始化但为空的切片是另一种状态。

DeepEqual 为什么要把 nil 状态算进去

reflect.DeepEqual 比较的是同类型值的深层结构。对于切片，官方定义包含三个条件：两者必须同时为 nil 或同时非 nil；长度相同；对应元素深度相等。只要第一条不满足，即使长度都是 0，也会直接得到 false。

这并不表示 nil 切片“不能用”。两种切片都可以参与 len、range 和 append。区别在于 nil 常常表示“没有提供结果、尚未初始化”，而空切片可能表示“已经计算过，结果明确为空”。当这个状态需要被上层识别时，DeepEqual 的 false 反而是有用的。

可以把它理解为两个层次：len(s) 只回答“有几个元素”，s == nil 回答“这个切片有没有初始化”，而 DeepEqual 同时关心这两个层次以及元素值。JSON 响应、缓存快照和结构体断言中，误把它们合并，往往就是断言失败的来源。

只关心内容时，应该怎么比较

如果产品语义是“两个结果都没有元素就算相同”，使用标准库 slices.Equal 更直接。它比较长度和每个元素，并明确把 nil 切片与空切片视为相等。元素类型需要满足 comparable；元素本身包含 map、slice 等不可比较字段时，应改用自定义比较函数。

package main

import (
	"fmt"
	"slices"
)

func main() {
	var nilItems []int       // 业务上代表“没有结果”
	emptyItems := []int{}    // 业务上代表“结果为空”

	// 只比较序列内容时，nil 与空切片按相等处理。
	fmt.Println(slices.Equal(nilItems, emptyItems))
}

如果项目版本或元素类型不适合使用 slices.Equal，也可以在比较边界统一规范化：

func normalize(items []int) []int {
	if items == nil {
		return []int{} // 对外约定空结果统一成非 nil 切片
	}
	return items
}

规范化要放在明确的边界上，例如响应组装层或断言辅助函数，不要在所有业务函数里无差别地把 nil 改成空切片。否则调用方失去区分“未计算”和“已计算为空”的机会。

API、JSON 和测试中最容易踩的边界

切片差异最常见的影响不在算法，而在数据边界。Go 的 JSON 编码通常会把 nil 切片编码为 null，把非 nil 空切片编码为 []；如果前端或接口文档只接受其中一种形态，服务端就要在输出前固定规则。这个决定和 DeepEqual 的语义不是一回事，不能靠换比较函数掩盖契约不一致。

测试时先写清楚断言意图：快照测试要检查结构和状态，就保留 DeepEqual；业务结果测试只关心列表内容，就使用 slices.Equal 或专门的断言工具。排查失败时依次打印 s == nil、len(s) 和元素内容，通常比直接打印切片值更快定位。

Go DeepEqual 与 nil 切片常见问题

为什么两个切片都能 range，DeepEqual 还会失败？

range 只读取元素，空切片和 nil 切片都没有元素；DeepEqual 还会检查切片是否同时为 nil，因此两者可以遍历行为一致但深度比较不相等。

把所有 nil 切片改成空切片是不是更好？

不是。对外 JSON 契约要求返回 [] 时可以在输出边界规范化；内部如果 nil 表示“未计算”或“未提供”，就应保留它。

元素是结构体时还能用 slices.Equal 吗？

只要结构体及其字段满足可比较条件就可以；包含 map、slice 或函数字段时，改用 slices.EqualFunc 或编写体现业务语义的比较函数。

排查断言失败先看什么？

先分别确认动态类型、s == nil、len(s) 和元素内容，再决定要保留 nil 差异还是只比较序列。不要只看日志里的 [] 展示结果。

因此，Go DeepEqual 比较 nil 切片和空切片不相等，是定义使然：它比较的是结构状态，而不只是可见元素。把“状态相等”“内容相等”和“接口输出相等”拆成三个问题，比较函数就会自然清晰。