Go 返回接口值时如何避免把 typed nil 传给调用方

Go 里最容易误判的一类“空值”是 typed nil：一个值为 nil 的指针被放进接口后，接口本身可能已经不再等于 nil。避免它的关键不是在调用方反复比较，而是在返回接口的函数里，把“没有结果”的分支直接返回接口层的 nil；只有确实有对象时，才把具体指针交给接口。返回 error 时也遵循同样原则：成功返回无类型 nil，失败才返回具体错误。

接口值要同时看动态类型和值。动态类型还在时，即使动态值是 nil，接口仍可能是非 nil。

本文只讨论接口返回、typed nil 和错误返回这条边界，不把反射当成所有问题的默认解法。

判断 typed nil：接口里同时藏着动态类型和值

假设有一个指针类型 *record，变量 var p *record 的指针值是 nil。若把它赋给 any 或某个接口，接口里仍然记录了动态类型 *record，所以 v == nil 通常为 false。相反，直接把无类型 nil 赋给接口时，动态类型和值都为空，接口才是 nil。

这也是为什么下面的判断不能证明“里面的指针一定非空”：它只回答接口外层是否有值。接口一旦被传给日志、回调或错误处理函数，调用方看到的就是这个外层状态。

package main

import "fmt"

type record struct{}

func main() {
	var p *record // 指针零值是 nil
	var v any = p // 接口保留了动态类型 *record
	fmt.Println(p == nil, v == nil) // true false：两层 nil 不是同一个判断
}

返回接口时，把 nil 放在接口层

接口返回函数最稳妥的写法，是让“未找到”分支直接返回 nil，不要先声明一个 nil 指针再无条件返回它。这样调用方的 result == nil 才有清晰含义。

type Item interface {
	Name() string
}

type item struct{ name string }

func (i *item) Name() string { return i.name }

func findItem(found bool) Item {
	if !found {
		return nil // 直接返回接口层 nil，调用方可正常判断
	}
	return &item{name: "配置项"} // 只有成功对象才装入接口
}

如果把 var result *item 后直接写成 return result，就会把 typed nil 传出去。一个实用的复查方式是沿着返回值问两句：无结果时返回的是哪一层的 nil？有结果时接口里装入的具体值是否真的已经初始化？

错误返回最容易踩中的位置

这个问题在 error 上更隐蔽，因为调用方通常只写一行 if err != nil。失败时返回具体错误指针没有问题，但成功时不能返回一个 typed nil 的错误指针。

type inputError struct{ Field string }

func (e *inputError) Error() string {
	return "字段无效：" + e.Field
}

func checkInput(valid bool) error {
	if valid {
		return nil // 成功分支必须返回真正的 nil error
	}
	return &inputError{Field: "name"} // 失败分支才携带具体错误
}

不要把“先声明错误指针、最后统一 return err”当成简洁写法，除非你已经保证成功路径会把接口层处理清楚。测试也应覆盖两条边界：成功时 err == nil，失败时既能进入 err != nil，又能通过类型断言读到 Field。

调用方与测试如何做复查

调用方优先修正返回函数的语义，而不是到处使用反射。只有在公共边界确实接收任意 interface{}，且必须识别指针、切片、映射、函数或通道的 nil 时，才考虑先判断 v == nil，再按允许的 kind 使用 reflect.Value.IsNil。对固定接口，明确返回契约通常比通用检测更安全、更容易测试。

几个容易混淆的问题

为什么类型断言成功后仍然可能拿到 nil 指针？

类型断言只说明接口里的动态类型符合目标类型，不会把 nil 指针变成非 nil 对象。断言成功后仍要检查得到的指针。

是不是所有接口都应该用 reflect 检查？

不是。固定接口和 error 应通过返回契约解决；反射只适合无法提前知道具体类型的通用边界。

参考：Go 语言规范、Go FAQ、Effective Go。