Go中interface{}变量即使装有nil指针，其自身也不为nil，故== nil返回false；正确判空需用reflect.IsNil()或类型断言后检查指针值。
Interface里存了个nil指针，== nil为什么还返回false
Go中interface{}变量本身不为nil，不代表它装的值是nil——只要接口被赋过值（哪怕是个nil指针），接口底层的type和value字段就都有内容了，此时iface == nil永远为false。
常见错误现象：if myInterface == nil 判断失效，导致空指针解引用panic或逻辑跳过。
- 接口变量只有在**从未被赋值**（零值）时才是nil；一旦做过
var i interface{} = (*MyStruct)(nil)这类赋值，接口就“活”了 - 真正要问的是：“它装的底层指针是不是nil？”——这得拆开看
value部分 - 不能靠
== nil，得用反射或类型断言配合判空
用reflect.Value检测接口内指针是否为nil
反射是最通用的办法，尤其适合处理未知类型的接口值。核心思路：先取reflect.Value，再检查它是否可寻址、是否是指针、其指向是否为nil。
使用场景：写通用工具函数、日志中间件、序列化前校验等需要统一处理任意interface{}的地方。
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 必须先调用
reflect.ValueOf(v).Elem()才能拿到指针指向的值，但前提是这个值确实是指针类型且非nil——所以得层层守卫 - 更安全的做法是：
reflect.ValueOf(v).Kind() == reflect.Ptr && !reflect.ValueOf(v).IsNil()只说明它是指针且非nil；而reflect.ValueOf(v).Kind() == reflect.Ptr && reflect.ValueOf(v).IsNil()才表示它是个nil指针 - 注意：
reflect.ValueOf(v).IsNil()对非指针/非slice/map/chan/func/unsafe.Pointer类型会panic，务必先用Kind()过滤
func isNilPtr(v interface{}) bool {
rv := reflect.ValueOf(v)
switch rv.Kind() {
case reflect.Ptr, reflect.Map, reflect.Slice, reflect.Chan, reflect.Func, reflect.UnsafePointer:
return rv.IsNil()
default:
return false
}
}
用类型断言+二次判空替代反射
如果已知接口大概率装的是某几种指针类型（比如*string、*int），类型断言比反射更快、更直观，也更容易排查问题。
性能影响：反射有明显开销，高频路径（如HTTP handler内部）应优先考虑断言分支；但类型太多时，维护成本上升。
- 断言失败时
v.(*string)会返回nil, false，此时不能直接用== nil判断原接口，而是看第二个返回值 - 正确姿势是：
if p, ok := v.(*string); ok && p == nil—— 先确保断言成功，再判指针本身 - 多个类型要逐个写
if-else if，不能用switch v.(type)直接判nil，因为case *string:分支里v已被转成*string，这时v == nil才有效
最容易被忽略的坑：nil接口 vs nil指针 vs nil底层数组
三者完全不是一回事。比如var s []int是nil切片，但interface{}(s)不是nil接口；又比如var p *int; var i interface{} = p，这时i不是nil，但p是nil。
兼容性影响：不同Go版本对reflect.Value.IsNil()行为一致，但老代码若混用== nil和反射，升级后可能暴露隐藏bug。
- 别依赖打印结果判断——
fmt.Println(i)输出<nil></nil>不代表i == nil成立 - 单元测试一定要覆盖“接口变量被显式赋了nil指针”这个用例，例如
var i interface{} = (*int)(nil) - 如果项目用了第三方库（比如
encoding/json或gob），它们内部对nil指针的处理逻辑可能和你预期不同，建议实测边界情况
