interface{} == nil 仅当类型和数据指针均为零值时才为真，故无法识别 *T(nil)、map[string]int(nil) 等带类型但值为空的情况；reflect.Value.IsNil() 仅适用于指针、切片、映射、通道、函数、不安全指针六种类型，且需先验证有效性与类型合法性；类型断言更轻量安全，高频路径应优先使用。
直接写 interface{} == nil 只能捕获“完全未赋值”的接口，对 (*T)(nil)、map[string]int(nil) 这类带类型但值为空的情况完全失效——这是最常踩的坑。
为什么 interface{} == nil 经常误判
Go 接口底层是两字段结构：_type（类型信息） + data（数据指针）。只有二者同时为零值，== nil 才返回 true。一旦你把一个 (*string)(nil) 赋给 interface{}，_type 就是非空的（指向 *string），整个接口就不等于 nil，哪怕它背后啥都没指向。
典型现象：
-
err != nil没进分支，但后续调err.Error()却 panic - HTTP handler 里收了个
interface{}参数，传了nil指针却没被识别 - 日志中间件想跳过空值，结果把
map[string]int(nil)当成有效值打了出来
用 reflect.ValueOf(x).IsNil() 的前提和限制
reflect.Value.IsNil() 不是万能钥匙，它只对六种类型安全：指针、切片、映射、通道、函数、不安全指针。对 int、string、struct 直接调会 panic。
必须分三步走：
- 先检查
v := reflect.ValueOf(x); if !v.IsValid()→ 排除reflect.ValueOf(nil)这种无效值 - 再判断
v.Kind()是否属于那六种可空类型之一 - 最后才调
v.IsNil() - 如果
v.Kind() == reflect.Interface，要先v.Elem()取出底层值，再重复上述三步（注意v.Elem().IsValid()必须为true）
错误示例：reflect.ValueOf(42).IsNil() → panic；reflect.ValueOf((*int)(nil)).Elem().IsNil() → panic（因为 .Elem() 对 nil 指针返回无效值）
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
更轻量、更可控的类型断言方案
如果你知道接口大概率是某几种类型（比如 HTTP 中常见 error、*User、map[string]interface{}），类型断言比反射快且不易出错。
- 对
error：直接用if err != nil—— 标准库约定nil error就是接口本身为nil - 对已知指针类型：
if p, ok := i.(*MyStruct); ok && p == nil - 对切片或 map：
if s, ok := i.([]byte); ok && s == nil或if m, ok := i.(map[string]int); ok && m == nil - 混合判断：
if i == nil { /* 真空 */ } else if p, ok := i.(*T); ok && p == nil { /* 类型匹配但指针空 */ }
高频路径别硬套反射，但通用工具函数得兜底
在循环、HTTP 中间件、序列化入口这种高频位置，避免无脑用 reflect.ValueOf。优先靠约定（比如函数文档注明“不接受 nil 指针”）或提前做类型断言。
但如果真要写一个通用 IsNil(interface{}) bool，必须递归处理 reflect.Interface 类型，并严格守三步守则。否则一碰到 int 或未导出字段就崩。
最容易被忽略的一点：你写的那个 IsNil 函数，永远无法告诉你「结构体里的某个指针字段是否为 nil」——那是另一层解包逻辑，不是接口判空的问题。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
