interface{}变量存储的是指针，指向值副本或原地址，取决于传入的是值还是指针；方法集是否匹配取决于接收者类型；大结构体传入易逃逸，指针可避免但需注意生命周期；eface无itab，iface有itab用于方法查找。
interface{} 类型变量存储的是值还是指针？
Go 的 interface{} 变量本身是一个两字长结构（iface），包含类型信息（itab）和数据指针（data）。关键点在于：它总是存储一个指向底层数据的指针，但这个指针指向的内容可能是栈上值的副本，也可能是原变量的地址——取决于你传入的是值还是指针。
例如：
type User struct{ Name string }
func f(v interface{}) { /* ... */ }
<p>u := User{Name: "Alice"}
f(u) // 传值：interface{} 内部 data 指向 u 的一份栈上拷贝
f(&u) // 传指针：interface{} 内部 data 直接存 &u 地址所以不是 interface「自己决定」传值或传指针，而是你调用时传了什么，它就包装什么。
为什么给 interface 赋值时方法集会失效？
接口能否接收某个类型，取决于该类型是否实现了接口要求的所有方法。而值类型和指针类型的方法集不同：
立即学习“go语言免费学习笔记（深入）”；
- 值类型
T的方法集：所有接收者为T的方法 - 指针类型
*T的方法集：所有接收者为T或*T的方法
常见错误：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
func (u User) GetName() string { return u.Name } // 值接收者
func (u *User) SetName(n string) { u.Name = n } // 指针接收者
<p>var u User
var i fmt.Stringer = u // ✅ ok：GetName 在 T 的方法集中
var j io.Writer = u // ❌ 编译失败：User 没有 Write 方法（且没实现 io.Writer）</p><p>// 更隐蔽的坑：
var i interface{ GetName() string } = &u // ✅ ok
var i interface{ GetName() string } = u // ✅ 也 ok（GetName 是值接收者）
var i interface{ SetName(string) } = u // ❌ 编译失败：SetName 只在 *User 方法集中interface{} 作为参数时，性能和逃逸分析怎么看？
把大结构体传给 interface{} 参数，容易触发不必要的堆分配（逃逸）：
- 传值：如果结构体较大（如 > 几十个字节），编译器通常会让它逃逸到堆，再由 interface{} 的
data字段指向它 - 传指针：避免复制，但要注意生命周期——不能传栈上局部变量的地址给可能长期存活的 interface{}
验证方式：
go build -gcflags="-m -l" main.go
关注输出中是否有 ... escapes to heap。小结构体（如 struct{int,int}）通常不逃逸；含 slice/map/chan 的类型几乎一定逃逸。
底层 iface 和 eface 的区别影响什么？
Go 有两个 interface 底层结构：
-
eface（empty interface）：只有_type和data，用于interface{} -
iface（non-empty interface）：多一个itab字段，用于带方法的接口（如io.Reader）
区别带来的实际影响：
- 空接口赋值开销略小（少一次
itab查找），但差别微乎其微 - 非空接口在首次赋值时需查找匹配的
itab（全局哈希表），存在极短延迟；后续相同类型复用缓存 -
itab不可变，因此接口转换（如interface{} → io.Reader）本质是查表 + 类型断言，不是运行时反射
真正该警惕的，是过度使用接口掩盖了本可静态绑定的调用路径，导致间接跳转和内联失效——这比底层结构差异更影响性能。
