在 Go 单元测试中，常会遇到这样的场景：被测函数返回一个指针类型（比如 *CustomType），而测试者关心的并非指针指向的结构体内容，而是它是否为 nil——换句话说，就是“是否返回了一个有效实例”。这种对指针存在性的验证，是编写可靠测试的基础。
最直观的做法当然是 if actual == nil { ... } 分支判断，但测试用例一多，满屏显式分支既啰嗦又容易漏判。其实有一种更优雅的写法，能把“存在性”校验浓缩成一行，且无需依赖任何第三方库，堪称 Go 单元测试中的“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{} 均可），就能直接使用。这是 Go 测试中验证“存不存在”的高效写法。
来看一个完整的测试示例：
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 测试中验证“存不存在”，这算得上一个惯用且健壮的实践，能有效减少测试代码中的冗余分支，提高维护效率。
