Go中error接口为nil需动态类型和动态值同时为nil；若为(*T)(nil)，类型非nil导致err==nil为false，故应统一用if err != nil判错。
Go 中 error 接口变量写成 if err == nil 看似安全，但一旦它底层是 (*MyError)(nil) 这类 typed nil，判断就会失效——因为接口值不等于 nil，哪怕它的动态值是个空指针。
为什么 (*T)(nil) 赋给 interface{} 后不等于 nil
Go 接口值在内存中是两个机器字：一个存类型信息（type descriptor），一个存数据指针（data pointer）。只有两者都为 nil 时，整个接口才真正为 nil。
-
var err error→ 类型=nil，值=nil →err == nil为 true -
var e *MyError = nil; err = e→ 类型=*MyError（非 nil），值=nil →err == nil恒为 false - 这种
(*T, nil)组合常出现在工厂函数返回、channel 发送、或错误包装逻辑中
哪些写法会意外制造 typed nil
以下模式极易在不察觉时把 nil 指针装进接口，导致判空失败：
- 直接返回
nil指针并赋给接口：如func NewErr() *MyError { return nil }，再写err := error(NewErr()) - channel 发送前未做判空：如
errChan ，接收端 <code>if err != nil仍进分支 - 类型断言后又转回接口：如
if e, ok := err.(*MyError); ok && e == nil { ... }，此时e是指针，err是接口，二者语义不同
正确判空的三类场景与写法
不要试图“解包再比”，而应按上下文选择最稳的判断方式：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 普通错误处理（推荐）：始终用
if err != nil—— 这是 Go 官方约定，且编译器对此有优化，语义清晰无歧义 - 需要区分“无错误”和“错误但为空”的场景（如 RPC 返回空 error 实例）：改用显式状态字段，例如
type Resp struct { Err error; HasError bool }，而非依赖接口判空 - 泛型/通用工具函数（如日志中间件、序列化 wrapper）：用
reflect.ValueOf(v).IsNil()辅助判断，但注意它对不可寻址值（如字面量、临时接口值）可能 panic，需先reflect.ValueOf(v).IsValid()
调试时怎么快速识别 typed nil
光看 fmt.Println(err) 或 fmt.Printf("%v", err) 容易误判，因为它们对 (*T)(nil) 也输出 <nil></nil>：
- 用
fmt.Printf("%#v", err)→ 显示完整结构，如(*main.MyError)(nil) - 用
fmt.Printf("type: %T, value: %v", err, err)→ 分开看类型和值 - 在调试器里 inspect 接口变量，观察其 runtime._iface 的 tab 和 data 字段是否均为 0
最易被忽略的一点是：不是所有 nil 都该被当成“无错误”。有些 typed nil 是合法中间态（比如异步任务尚未完成时的占位 error 值），强行用反射兜底反而掩盖了设计意图。判空逻辑必须和业务语义对齐，而不是堆技术技巧。
