如何简洁断言 Go 函数返回值的存在性（nil 或非 nil）

在 Go 单元测试里，常常会遇到这样一种场景：被测函数返回一个指针类型（比如 *CustomType），而测试关心的并不是指针指向的结构体里到底装了什么东西，只是想知道它是不是 nil——说白了，就是“有没有返回一个有效实例”。

最直觉的做法当然是用 if actual == nil { ... } 去分支判断，但要是测试用例一多，满屏都是这种显式分支，读起来既啰嗦又容易出错。其实有一个更优雅的写法，能把“存在性”校验浓缩成一行，而且不依赖任何第三方库。

先说说为什么直接写 actual == case.Expected 不行。假如 Expected 是 &CustomType{}，actual 也是 &CustomType{}——这俩虽然是语义等价，但地址不同，所以结果恒为 false。只有 nil 等于 nil 时会通过，但那种覆盖显然不够完整。

那么，正确的做法是什么？

把“是否为 nil”抽象成一个布尔值，然后比较两个布尔值是否一致。最简洁的写法就是：

if (actual == nil) != (case.Expected == nil) {
    t.Fatalf("expected existence %t, but got %t for input %q",
        case.Expected != nil, actual != nil, case.Input)
}

这个表达式 (actual == nil) != (case.Expected == nil) 的逻辑非常直白：当两者 nil 状态不一致时，结果为 true，触发失败。它不关心具体类型，只要该类型可以和 nil 比较（指针、切片、map、func、channel、interface{} 都可以），就能拿来用。

来看一个完整的测试示例：

func TestSomeFunc(t *testing.T) {
    tests := map[string]struct {
        Input    string
        Expected *CustomType
        Err      error
    }{
        "returns concrete value": {
            Input:    "valid",
            Expected: &CustomType{},
            Err:      nil,
        },
        "returns nil on error": {
            Input:    "invalid",
            Expected: nil,
            Err:      ErrSomeError,
        },
    }
    for name, tt := range tests {
        t.Run(name, func(t *testing.T) {
            actual, err := SomeFunc(tt.Input)
            // 断言返回值存在性（nil/non-nil 一致性）
            if (actual == nil) != (tt.Expected == nil) {
                t.Fatalf("existence mismatch: expected %v, got %v",
                    tt.Expected != nil, actual != nil)
            }
            // 断言错误匹配（可选）
            if !errors.Is(err, tt.Err) {
                t.Fatalf("error mismatch: expected %v, got %v", tt.Err, err)
            }
        })
    }
}

一些值得注意的细节：

• 避免使用 reflect.DeepEqual(actual, tt.Expected)——它对指针比较的是地址，而且 nil 与空结构体指针不等价，容易误导。
• 不要省略 != 后面的括号。Go 运算符优先级要求 (actual == nil) 必须括起来，否则 actual == nil != tt.Expected == nil 会被解析错。
• 如果还需要验证非 nil 值的内部字段，请在 actual != nil 分支里单独断言，别混进存在性检查里。
• 这个模式天然兼容 nil 安全的 interface{} 类型（如 io.Reader），只要底层值满足 nil 判定规则。

总结一下：用 (a == nil) != (b == nil) 代替繁琐的四分支条件，既提升了可读性，又消除了对具体类型的耦合。在 Go 测试里验证“存不存在”，这算得上一个惯用且健壮的实践了。