Go 接口值在内存里到底占几个字？
Go 的接口值（iface）不是指针，也不是单纯的数据拷贝，而是一个两字宽的结构体：第一个字是类型信息指针（_type），第二个字是数据指针（data）。哪怕你传一个 int 或一个空 struct，只要它被装进接口，就固定占 16 字节（64 位系统）。
这解释了为什么空接口 interface{} 接收小整数时看似“没开销”，实则每次赋值都发生两次指针写入——类型信息不能省，data 也不能跳过（哪怕指向栈上一个 int 的地址）。
- 非空接口（如
io.Writer）用的是iface；空接口用的是eface，结构类似但字段名和细节略有不同，别混用概念 - 接口值本身可比较（
==），但只在两者类型相同、底层数据可比且相等时才为 true；nil 接口和 nil 指针不等价 - 把一个栈变量取地址再转接口，
data字段存的是该变量地址——如果变量生命周期结束（比如函数返回），data就成悬垂指针，但 Go 编译器会自动逃逸分析并把它挪到堆上
为什么 interface{}(42) 和 interface{}(&42) 都能编译，但行为完全不同？
因为 interface{} 接收值时，会根据右值是否为指针类型，决定 data 字段存什么。传 42，data 指向一个新分配的堆上 int；传 &42，data 直接存这个地址——但 &42 本身非法（字面量不可取址），实际常见的是 &x（x 是变量）。
关键点在于：接口不关心你传进来的是值还是指针，它只认「能提供类型信息 + 数据地址」的东西。所以 fmt.Println(interface{}(42)) 和 fmt.Println(interface{}(&x)) 都合法，但后者若 x 是局部变量，逃逸后堆分配，data 存的仍是有效地址。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 传值：类型信息指向
int，data指向堆上一份int副本 - 传指针：类型信息指向
*int，data就是原指针值（不额外复制目标对象） - 误以为 “接口能透明代理指针语义” 是常见错觉——
var i interface{} = &x后，i里存的是*int类型，不是int；对i做类型断言必须用.(*int)，用.(*int)断言失败会 panic
类型断言失败时 panic 还是返回零值？取决于写法
用双返回值形式（v, ok := i.(T)）不会 panic，ok 为 false；单返回值（v := i.(T)）会在类型不匹配时直接 panic。这不是语法糖，而是编译器生成的完全不同的指令路径。
背后原因是：单返回值版本跳过了类型检查分支，直接按 T 解析 data 字段内容，一旦类型不符，data 可能指向错误内存布局，读出来就是垃圾或触发 segfault（Go runtime 会先做类型校验，所以实际表现为 panic）。
- 生产代码一律用双返回值，尤其处理用户输入或外部数据时
- 空接口
interface{}断言失败成本低；非空接口（如Stringer）断言前，runtime 要先查类型方法集是否实现该接口，有轻微开销 - 嵌套接口断言（如
i.(interface{ String() string })）是合法的，但会触发动态方法查找，比静态已知类型慢
unsafe.Sizeof(interface{}) == 16，但为什么有时看汇编发现 movq 写了两次？
因为 iface 的两个字段（tab 和 data）在寄存器中通常由两个独立 movq 指令写入——即使它们在内存里连续。这不是 bug，是 ABI 要求：Go 的调用约定不保证多字段结构体通过单条指令传递。
这也意味着，对接口值做原子操作（如 atomic.StorePointer）是无效的：你只能原子地存一个指针，而 iface 是两字宽值类型。真要并发安全地替换接口值，得用 sync/atomic 提供的 StoreUintptr 配合自定义对齐结构，或者直接上互斥锁。
- 不要对接口值本身做
unsafe.Pointer强转后修改字段——tab和data是内部字段，名字和偏移可能随版本变 -
reflect.ValueOf(i).Interface()返回新接口值，不是原值的引用，修改返回值不影响原变量 - 接口值的
data字段可能为 nil（比如 var w io.Writer），此时调用其方法会 panic: "nil pointer dereference" —— 这个 nil 是data字段的 nil，不是接口变量本身的 nil
