在 go 中，接口变量为 nil 的判定需同时满足两个条件：底层类型和底层值均为 nil；若类型非 nil 而值为 nil（如 *t(nil)），该接口仍不等于 nil。这是初学者易踩的“伪 nil”陷阱。
在 go 中，接口变量为 nil 的判定需同时满足两个条件：底层类型和底层值均为 nil；若类型非 nil 而值为 nil（如 *t(nil)），该接口仍不等于 nil。这是初学者易踩的“伪 nil”陷阱。
Go 的 error 类型是一个内置接口：type error interface { Error() string }。当我们将一个具体类型的指针（例如 *TestError）赋值给 error 变量时，该接口值便由两部分组成：动态类型（dynamic type） 和 动态值（dynamic value）。只有当二者同时为 nil 时，该接口值才真正等于 nil。
在你的示例中：
func NewTestError(err error) *TestError {
if err == nil {
return nil // 返回 nil 指针
}
return &TestError{Message: err.Error()}
}NewTestError(err) 的返回类型是 *TestError（即 *main.TestError），而你在 main() 中执行了：
err = NewTestError(err) // err 是 error 接口类型
此时，err 接收的是一个 *TestError 类型的值 —— 但注意：NewTestError 在 err == nil 时返回 nil，这个 nil 是 *TestError 类型的零值，而非未初始化的接口。Go 会将 nil 指针连同其类型 *TestError 一起装箱到 error 接口中。结果是：
- 动态类型：*main.TestError（非 nil）
- 动态值：nil（指针值为 nil）
因此 err == nil 判定为 false，尽管 err 的底层指针是 nil。这也解释了日志输出：
main( ... ): err == nil. false main( ... ): err = (*main.TestError)(nil)
—— 接口非 nil，但其内部存储了一个类型明确、值为 nil 的指针。
✅ 正确写法：确保返回的是接口层面的 nil，而非具体类型的 nil 指针：
func NewTestError(err error) error { // 返回 error 接口，而非 *TestError
if err == nil {
return nil // ✅ 真正的 interface{}(nil) / error(nil)
}
return &TestError{Message: err.Error()} // ✅ 自动装箱为 error 接口
}⚠️ 关键注意事项：
- 不要将 nil 指针直接赋给接口变量，除非你明确希望保留该类型信息；
- 在函数签名中返回具体指针类型（如 *TestError）再赋值给接口，极易引发“类型残留”，导致 == nil 失效；
- 使用 errors.Is(err, nil) 或直接 if err != nil 是安全的，但前提是 err 确实来自标准错误传播路径（如 io、fmt 函数返回），而非手动构造的带类型 nil；
- 调试时可用 fmt.Printf("%#v", err) 查看完整接口状态，或通过反射检查：reflect.ValueOf(err).IsNil()（仅适用于可比较的底层类型）。
总结：Go 接口的 nil 判定是「类型 + 值」双重空性判断。理解这一点，是写出健壮错误处理逻辑的基础。始终让错误构造函数返回 error 接口类型，并在 nil 分支中返回字面量 nil，即可避免此类陷阱。
