Go接口是隐式实现，仅按方法签名匹配判断；接收者类型影响实现：*T接收者要求指针，T接收者值和指针均可；空接口被所有类型实现；编译期断言var _ I = (*T)(nil)最可靠。
Go 语言中没有显式的“实现接口”语法，只要类型的方法集满足接口定义，就自动实现了该接口——这是隐式实现，不是继承，也不需要 implements 关键字。
接口定义后，哪些类型算“实现了它”？
判断依据只有方法签名（名称 + 参数类型 + 返回类型）是否完全匹配，不看方法名以外的任何东西。接收者类型（值 or 指针）会影响方法集，进而影响是否满足接口：
- 如果接口方法的接收者是
*T，那么只有*T类型（或能隐式转换为它的类型）才拥有该方法；T值本身不包含该方法 - 如果接口方法的接收者是
T，那么T和*T都拥有该方法（因为 Go 允许对指针调用值接收者方法） - 空接口
interface{}被所有类型自动实现
常见错误：定义了 func (t T) Method()，却试图把 &t 赋给只含 Method() 的接口变量——这没问题；但反过来，若方法是 func (t *T) Method()，却传入 t（非指针），就会编译失败：cannot use t (type T) as type MyInterface in assignment: T does not implement MyInterface (Method method has pointer receiver)
如何检查某个类型是否实现了某接口？
最稳妥的方式是在包内加一行编译期断言：
var _ MyInterface = (*MyStruct)(nil)
这行代码不执行，只在编译时验证：*MyStruct 是否满足 MyInterface。如果没实现，会直接报错，且错误信息明确指向这一行。
其他方式容易出错：
- 用
var _ MyInterface = MyStruct{}—— 若接口要求指针接收者方法，这里会失败 - 运行时反射判断（
reflect.TypeOf(t).Implements(...)）—— 不推荐，失去编译期保障，且不能反映指针/值接收者的差异
接口嵌套与组合的典型误用场景
接口可以嵌套，比如 type ReadWriter interface { Reader; Writer }，但它只是语法糖，等价于把两个接口的所有方法平铺合并。注意以下几点：
- 嵌套不传递实现：即使
A实现了Reader，B实现了Writer，也不能靠“A+B”凑出ReadWriter；必须同一个类型同时有全部方法 - 方法名冲突不会自动解决：如果两个嵌入接口都有
Close() error，没问题；但如果一个是Close() error，
另一个是
Close() bool，则无法嵌套，编译报错 - 避免过度设计：不要为了“看起来像 Java”而层层嵌套接口，Go 接口应小而专（如
io.Reader只有一个Read方法）
最容易被忽略的是接收者类型和接口满足关系之间的耦合——写方法时随手用 *T 接收者，后续传值就卡住；或者测试时用值传参能过，上线用指针传参就 panic。务必在定义接口之初就想清楚调用方持有的是值还是指针，并保持一致。
