Go接口判空失败是因为接口为nil需类型和值字段同时为nil；仅值为nil时接口非nil，故==nil失效，应优先用err!=nil判错，泛型场景用reflect.ValueOf(v).IsNil()或类型断言。
Go 接口变量判空失败，不是因为你写错了，而是因为 err == nil 的语义和你直觉里的“空”根本不是一回事——接口为 nil 必须同时满足：类型字段为 nil 且值字段为 nil；只要其中一个是具体类型（哪怕值是 nil），整个接口就不等于 nil。
为什么 err == nil 有时返回 false，但打印出来却是 <nil></nil>
这是最典型的表象矛盾。比如：
func doWork() *MyError { return nil }
var err error = doWork() // 此时 err 类型是 *MyError，值是 nil
fmt.Printf("%v\n", err) // 输出: <nil>
fmt.Println(err == nil) // 输出: false
原因在于：err 是一个接口值，底层结构是 (type: *MyError, data: nil)。类型字段非 nil，所以整个接口不为 nil。而 fmt 包在打印时只看 data 字段，发现是空指针就输出 <nil></nil>，掩盖了类型字段已填充的事实。
- 这种现象常见于自定义错误构造函数、RPC 返回值、JSON 解析后赋值给
interface{}等场景 - 它不会导致编译错误，但会让
if err != nil分支意外执行，甚至引发 panic（比如调用err.Error()） - 不要依赖
fmt.Printf输出判断接口是否为空——它不可靠
error 接口判空必须用 err != nil，而不是解包后比较
Go 社区约定和语言设计都要求：对 error 唯一安全、标准的检查方式就是直接比较接口本身，即 if err != nil。任何试图先断言再判空的做法，要么冗余，要么危险。
立即学习“go语言免费学习笔记（深入）”；
- 错误写法：
if e, ok := err.(*MyError); ok && e == nil—— 这里e == nil是对指针判空，和err是否为 nil 无关 - 更错写法：
if err.(*MyError) == nil—— 类型断言失败会 panic，不是判空逻辑 - 正确姿势：始终用
if err != nil，这是 Go 运行时保证行为一致的唯一路径 - 如果你需要区分“无错误”和“错误值为 nil 的具体类型”，说明接口抽象已被破坏，应重构错误构造逻辑
如何安全地检查 interface{} 内部值是否为 nil 指针
当必须处理泛型接口（如 interface{}）且需确认其内部是否为某个类型的 nil 指针时，不能只靠 == nil，得拆开看。
- 首选方案：用
reflect.ValueOf(v).IsNil()，但仅适用于可空类型（Ptr、Slice、Map等），且要先确保v有效：reflect.ValueOf(v).IsValid() - 手动展开更高效：若只处理几种已知类型，直接类型断言 + 指针判空，例如：
if p, ok := v.(*bytes.Buffer); ok && p == nil - 避免反射的场景：HTTP 客户端传
io.Reader时，别写var r *bytes.Reader; req, _ := http.NewRequest("GET", u, r)，而应直接传nil字面量，让接口真正为 nil - 注意：对不可寻址值（如 struct 字段未导出）调用
reflect.ValueOf(v).IsNil()会 panic
面试常问：为什么 var i interface{} = (*int)(nil) 不等于 nil
这个问题直指 Go 接口底层模型。答案不是“因为它被赋值了”，而是：接口变量本质是双字结构，var i interface{} 初始化后是 (_type: nil, data: nil)；而 i = (*int)(nil) 后变成 (_type: *int, data: nil) —— 类型字段已写入，不再满足 nil 条件。
- 空接口
interface{}底层是eface结构；带方法的接口（如error）是iface，但 nil 判断规则一致 - 面试官想听的不是“两字段都得 nil”，而是你能说出
_type和data这两个字段名，并指出它们在runtime2.go中的定义 - 延伸陷阱：
nil接口可以参与类型断言，但断言失败时返回零值 +false，不是 panic；而nil指针解引用才会 panic - 真正容易被忽略的是：这个机制不是 bug，是 Go 故意为之的设计——它让接口能承载“有类型但无值”的状态，支撑了像
http.NewRequest中 body 为nil与*bytes.Reader(nil)的语义区分
