Go reflect.Value 怎么安全判断一个接口是否为 nil

Go 里最容易误判的一类 nil，是接口里装着一个 typed nil 指针：接口本身并不等于 nil，但它保存的指针确实是 nil。反射再多一层陷阱：reflect.ValueOf(nil) 返回无效的零值，直接调用 IsNil 会 panic。

实战中可以把判断顺序固定成三步：先用普通比较处理接口自身是否为空；再调用 Value.IsValid()；最后只对白名单 Kind 调用 IsNil()。这样既能识别 typed nil，也不会把普通整数、结构体等值误送进反射方法。

先区分接口自身为空和 typed nil

接口值可以理解成“动态类型 + 动态值”的组合。只有两个槽位都为空时，接口才等于 nil。因此下面的 p 虽然指向 nil，但赋给 any 后接口里仍然有 *User 这个动态类型。

type User struct{}

func main() {
	var empty any
	var p *User
	var typed any = p

	fmt.Println(empty == nil) // true：接口没有动态类型和值
	fmt.Println(typed == nil) // false：接口保留了 *User 类型
}

这也是很多参数校验“明明是 nil 却没拦住”的原因。若业务只接受明确的 *User，优先做类型断言并判断指针；若入口必须接受任意类型，才需要进入反射。

先检查 reflect.Value 是否有效

reflect.ValueOf(v) 的返回值不是普通的“装了 nil 的 Value”。当 v 是一个真正的 nil 接口时，返回的是零值 Value，它没有有效的类型和数据。官方文档明确说明，无效 Value 除了调用 String 外，其他大多数方法都可能 panic。

func inspect(v any) string {
	rv := reflect.ValueOf(v)
	if !rv.IsValid() {
		return "invalid: nil interface" // 先处理 ValueOf(nil)
	}
	return rv.Kind().String() // Value 有效后才读取 Kind
}

不要用 rv.IsNil() 代替 rv.IsValid()。对 reflect.ValueOf(nil) 来说，问题不是“某种 Kind 的值为 nil”，而是根本没有可供反射操作的值。

按 Kind 安全调用 IsNil

处理任意 any 时，可以把允许调用 IsNil 的 Kind 写成白名单。reflect.Kind 是枚举值，普通的 int、struct、array 和 string 都不能直接调用 IsNil。

func isNilLike(v any) bool {
	if v == nil {
		return true // 接口自身为空，不必进入反射
	}

	rv := reflect.ValueOf(v)
	switch rv.Kind() {
	case reflect.Chan, reflect.Func, reflect.Interface,
		reflect.Map, reflect.Pointer, reflect.Slice:
		return rv.IsNil() // 只有文档允许的 Kind 才调用 IsNil
	default:
		return false // 数字、结构体、字符串等不是 nil-able Kind
	}
}

这个函数会把 nil interface 和 typed nil 都判断为 true，也会把 nil map、nil slice、nil channel 和 nil function 识别出来。需要注意的是，空但已分配的 slice 或 map 不是 nil；例如 make([]int, 0) 和 []int(nil) 的长度都可能为 0，但 nil 状态不同。

把判断封装到反射边界

反射通常出现在参数校验、序列化适配器或日志工具的边界。把防护集中在一个函数里，比在多个业务分支中散落 Kind 判断更容易维护。若业务还要区分“接口空”和“typed nil”，可以返回状态而不是只返回 bool。

type NilState int

const (
	NotNil NilState = iota
	NilInterface
	NilValue
)

func nilState(v any) NilState {
	if v == nil {
		return NilInterface // 没有动态类型的接口
	}
	rv := reflect.ValueOf(v)
	switch rv.Kind() {
	case reflect.Chan, reflect.Func, reflect.Interface,
		reflect.Map, reflect.Pointer, reflect.Slice:
		if rv.IsNil() {
			return NilValue // 接口有动态类型，但底层值为空
		}
	}
	return NotNil
}

测试时至少覆盖三组输入：真正的 nil 接口、持有 nil 指针的接口，以及普通不可空值。再补一个空 slice 与 nil slice，能避免把“长度为零”错误当成“值为 nil”。

常见问题

为什么 typed nil 接口不等于 nil？

接口仍保存了动态类型，例如 *User；只有动态类型和值都为空时，接口才等于 nil。

可以直接对所有 reflect.Value 调用 IsNil 吗？

不可以。先排除无效 Value，再检查 Kind；对 int、struct 等不可空 Kind 调用会 panic。

nil slice 和空 slice 有什么区别？

两者长度都可以是 0，但 nil slice 没有底层数组，空 slice 通常已经有一个可用的 slice 描述。需要判断 nil 状态时，应使用安全函数而不是只看长度。

业务代码应该优先反射还是类型断言？

已知参数类型时优先类型断言或直接比较指针；只有通用适配器确实需要接收任意类型时，才把反射判断封装在边界层。

记住这条顺序即可：接口先比较 nil，Value 先检查有效性，Kind 再决定能否调用 IsNil。它解决的不是 nil 语法本身，而是把接口的动态类型和值、反射的零值与可空类型放回各自的判断层级。