go中接口变量底层是两个字宽的iface结构体，仅当tab和data均为nil时才是真nil；若tab非nil（如(*t)(nil)赋值），接口不为nil但data为空指针。
nil 接口变量的底层结构是什么
Go 中的接口变量本质是两个字宽的结构体：type iface struct { tab *itab; data unsafe.Pointer }。当接口变量为 nil 时，tab 和 data 都为 nil —— 这才是“真 nil”。它既没类型信息，也没值指针。
常见错误现象：用 fmt.Printf("%v", interface{}(nil)) 看起来像 <nil></nil>，就以为它能安全传给任何函数；但一旦函数内部做类型断言或反射操作，就会 panic 或行为异常。
- 只有
tab == nil && data == nil才算接口层面的nil - 只要
tab != nil（哪怕data == nil），该接口变量就不等于nil - 这种“非空接口但空值”的状态，在 JSON 解析、gRPC 反序列化、ORM 字段赋值时极易暴露
(*T)(nil) 赋值给接口后为什么不是 nil
当你写 var p *int; var i interface{} = p，i 的 tab 指向 *int 类型的 itab，data 指向 nil 地址。此时 i == nil 判断为 false —— 因为类型信息存在。
使用场景：常出现在构造器返回 interface{}、泛型约束边界、或封装指针类型时。比如 func New() io.Reader 返回 (*bytes.Buffer)(nil)，调用方若只判 if r == nil 就会漏掉这个“有类型、无值”的情况。
立即学习“go语言免费学习笔记（深入）”；
-
(*T)(nil)→ 接口变量：类型已知，值指针为nil，接口变量本身不为nil - 直接
var i interface{} = nil→ 接口变量：类型和值都未知，接口变量为nil - 性能上几乎无差异，但逻辑判断路径完全不同；兼容性上，Go 1.0 以来行为稳定，但很多老代码仍假设“接口 nil 就等于值 nil”
如何安全判断接口里是否存了有效的 *T 值
不能只靠 if i == nil，得结合类型检查和值检查。最稳妥的方式是先断言，再判指针是否为空。
示例：if p, ok := i.(*os.File); ok && p != nil —— 这里 ok 确保类型匹配，p != nil 确保指针有效。
- 避免
if i != nil { v := i.(*T); ... }：一旦类型不对直接 panic - 避免
reflect.ValueOf(i).IsNil()对接口变量：它只对 reflect.Value 有效，且对非指针/非 slice/map/channel 类型 panic - 在 HTTP handler、中间件、mock 测试中，尤其要注意
http.ResponseWriter等接口被传入(*responseWriter)(nil)的情况
为什么 fmt.Println 和 == 对接口的输出/比较行为让人困惑
fmt.Println 输出 (*T)(nil) 接口时显示 <nil></nil>，和真 nil 接口看起来一样；但 == 比较时它们完全不等。这是因为 fmt 只看 data 是否为空指针，而 == 是对整个 iface 结构做字节比较。
错误现象：单元测试里用 assert.Equal(t, want, got) 判定接口相等失败，但打印出来都是 <nil></nil>，排查半天才发现一个是 nil，另一个是 (*string)(nil)。
-
fmt.Stringer实现不影响接口本身的 nil 判定逻辑 - JSON 序列化时，
(*T)(nil)接口会输出null，但反序列化回来可能变成真nil（取决于解码器实现） - 最容易被忽略的是：类型别名、嵌入接口、或通过泛型参数传递接口时，
tab的地址可能因编译器优化而不同，导致本该相等的两个(*T)(nil)接口变量==结果为 false
