go接口实现判定由编译期静态检查确保赋值合法性，运行时动态绑定决定方法调用目标；赋值时编译器立即验证类型是否满足接口，方法调用时才通过itab查表跳转。
Go 接口的实现判定不是在运行时才“猜”，而是编译期静态检查 + 运行时动态调用的混合机制。你写 var x io.Writer = &os.File{}，编译器立刻就知道 &os.File{} 满足 io.Writer；但真正调用 x.Write() 时，才根据底层值的类型查表跳转——这才是“延迟绑定”真正发生的地方。
接口赋值时的实现检查发生在编译期
Go 不允许运行时才决定某个类型是否实现了接口。只要出现 var i fmt.Stringer = myType{} 这类赋值，编译器就立刻检查 myType 是否有 String() string 方法。没有？直接报错：cannot use myType{} (type myType) as type fmt.Stringer in assignment: myType does not implement fmt.Stringer (missing String method)。
- 这个检查不依赖变量是否为空、是否 nil，只看类型定义本身
- 哪怕你把
myType{}换成nil（如var t *myType; var i fmt.Stringer = t），只要*myType实现了该接口，依然能通过编译 - 接口类型之间赋值（如
var w io.ReadWriter = &bytes.Buffer{}）也走同样路径：编译器确认&bytes.Buffer{}同时满足io.Reader和io.Writer，才允许它赋给更宽泛的io.ReadWriter
接口方法调用才是真正的动态绑定
一旦接口变量被赋值，它的底层类型和方法集就固定了，但具体调哪个函数体，要等到 i.String() 执行那一刻才确定。Go 运行时维护一张“接口方法表”（itab），里面存着目标类型的函数指针。这个查找过程是动态的，且不可绕过。
- 即使你传入的是
nil接口值（var i fmt.Stringer），调用i.String()也会 panic：nil pointer dereference，因为此时 itab 为空，无法跳转 - 如果接口变量非 nil，但底层类型的方法里有 panic，那 panic 发生在运行时，不是编译期能预知的
- 性能上，一次接口方法调用比直接调结构体方法多一次 itab 查找 + 间接跳转，但现代 CPU 分支预测已大幅削弱这部分开销
空接口 interface{} 的特殊性
interface{} 是唯一不需要显式实现声明的接口——任何类型都自动满足它。但它不是“无约束”，而是约束为“没有任何方法”。它的动态绑定体现在类型信息存储上：每个 interface{} 值内部包含两个字：一个指向类型描述符（*rtype），一个指向数据指针。
- 赋值
var i interface{} = 42时，编译器生成代码把int的类型信息和值 42 的副本一起塞进接口结构体 - 类型断言
v := i.(int)不是“转换”，而是运行时比对 itab 中的类型指针是否等于&int的地址；不匹配就 panic - 切片、map 等不能比较，但
interface{}可以比较——前提是两个接口值的底层类型相同且值相等（比如两个int都是 42）；若一个是int，一个是int32，即使数值一样，比较结果也是false
容易被忽略的组合陷阱
嵌入结构体时，方法提升（method promotion）会让外层类型“看起来”实现了某个接口，但实际可能只是部分满足——尤其当嵌入类型的方法接收者是指针时。
-
type A struct{}有func (A) M(){}，嵌入到B中：type B struct{ A }→B{}能调M()，也能赋给对应接口 - 但若
A的方法是func (*A) M(){}，那么B{}的字段A是值类型，无法自动取地址，B{}就不满足该接口；必须写type B struct{ *A }或显式取地址&B{} - 这种差异不会在编译期报错（因为
B本身没声明实现接口），而是在你尝试赋值时才暴露：var i MyInterface = B{}报错
接口实现判定看似简单，但编译期检查和运行时跳转的分工边界很关键：赋值安全靠编译器兜底，调用行为由运行时决定。别指望靠反射或运行时判断“某个类型是否实现了某接口”，Go 的设计哲学就是——该知道的，编译期必须知道；该晚点决定的，运行时才决定。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
