go接口值为nil需动态类型和动态值同时为nil；若为(*myerror)(nil)，类型非nil导致err==nil为false，而fmt仅看data字段故输出。
为什么 err == nil 有时返回 false，但 fmt.Println(err) 却输出 <nil></nil>
这不是 bug，是 Go 接口的底层结构决定的。接口值本质是两个字宽：一个存类型（_type），一个存数据指针（data）。只有两者都为 nil，整个接口才等于 nil。
常见触发场景：
- 函数返回
(*MyError)(nil)，再赋给error接口 → 类型字段是*MyError（非nil），值字段是nil→ 接口整体 ≠nil - RPC 或 JSON 解析后，把
nil指针直接转成interface{}→ 同样只填了类型，没填值 - 通道接收
，而发送端发的是 <code>var e *exec.Error = nil
fmt 包打印时只看 data 字段，发现为空就输出 <nil></nil>，完全不关心类型字段是否已填充——所以视觉上“像 nil”，逻辑上却不是。
if err != nil 是唯一安全的错误检查写法
Go 社区约定和运行时保证都基于这个模式。它不依赖你对底层类型的了解，也不要求你做任何类型断言或反射操作。
以下写法全是错的：
-
if e, ok := err.(*MyError); ok && e == nil→ 这是在判断指针是否为空，跟err是否为接口nil无关 -
if err.(*MyError) == nil→ 类型断言失败直接 panic，根本走不到比较 -
if reflect.ValueOf(err).IsNil()→ 对不可寻址接口（比如从函数返回的）会 panic，且性能开销大，仅适合调试
正确姿势就是原样写：if err != nil { ... }。这是语言设计强制你遵守的契约，不是风格偏好。
泛型或 interface{} 场景下如何安全判空
当你无法预知具体类型（比如函数参数是 interface{}），又必须确认内部是否为某个类型的 nil 指针时，== nil 不再可靠。
可行方案按优先级排序：
- 若只处理有限几种类型，直接类型断言 + 指针判空：
if p, ok := v.(*bytes.Buffer); ok && p == nil - 需要泛化支持时，用
reflect.ValueOf(v)，但必须先.IsValid()：rv := reflect.ValueOf(v); rv.IsValid() && rv.Kind() == reflect.Ptr && rv.IsNil() - 避免把
nil指针塞进接口；构造函数应显式返回nil接口值，而不是让调用方自己装箱
注意：reflect.ValueOf(v).IsNil() 对非指针、非 slice/map/chan 等可空类型会 panic，不能无条件调用。
自定义错误构造函数最容易踩的坑
这类函数常返回 *MyError，然后被隐式转成 error 接口。一旦返回 nil 指针，就埋下陷阱。
典型错误模式：
func NewError(msg string) *MyError {
if msg == "" {
return nil // 返回裸 nil 指针
}
return &MyError{msg}
}
err := error(NewError("")) // 此时 err != nil！
修复方式很简单：让函数直接返回 error 类型，并在 nil 时返回接口零值：
func NewError(msg string) error {
if msg == "" {
return nil // 直接返回 nil 接口，不是 *MyError(nil)
}
return &MyError{msg}
}
关键点在于：不要让 nil 指针经过接口装箱过程。类型信息一旦写入接口，就再也擦不掉了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
