Go接口是隐式实现的行为契约，仅由方法签名匹配决定，无需显式声明；本质是方法集合的快照，不描述类型而约定能力，赋值失败常见于接收者类型、签名不一致或大小写错误。
Go 接口不是“类实现契约”的传统理解，而是“只要能做某事，它就是那个角色”——完全隐式、无需声明、不看类型名，只看方法签名是否匹配。
接口到底是什么：不是类型定义，而是行为快照
Go 中的 interface 本质是一组方法签名的集合，没有字段、没有实现、不能实例化。它不描述“是什么”，只约定“能做什么”。比如：
type Reader interface {
Read(p []byte) (n int, err error)
}
只要某个类型有完全一致的 Read 方法（参数、返回值类型和顺序都相同），它就自动是 Reader——哪怕你从没写过 implements Reader 这种词。
- 结构体、自定义类型别名（如
type MyString string）、甚至其他接口都能实现接口 - 空接口
interface{}是特例：因无任何方法，所有类型都自动满足，等价于“任意类型” - 接口变量本身只存两样东西：
动态类型（底层真实类型）和动态值（具体数据），不是指针也不是拷贝
为什么不用 implements？隐式实现的真实好处
显式声明（如 Java）要求实现者提前知道并耦合接口定义；Go 的隐式实现让代码更解耦、更易演化：
立即学习“go语言免费学习笔记（深入）”；
- 已有类型（比如标准库的
bytes.Buffer）可以“事后”被当作io.Writer用，无需修改源码 - 测试时可轻松用轻量 mock 类型替代真实依赖，只要方法一致即可
- 第三方包升级后新增方法？只要你不调用它，老接口依然兼容——因为接口是“最小契约”
- 但这也带来风险：若误删/改名一个方法，编译器仍通过（因无人显式声明实现），直到运行时或调用处才暴露
常见误判点：接口赋值失败的三个典型原因
看似实现了所有方法，却无法赋值给接口？大概率掉进以下坑里：
-
值接收者 vs 指针接收者：若接口方法由*T实现，而你传的是T变量（非地址），会报cannot use xxx (type T) as type Y in assignment - 方法签名不严格一致：比如返回
error写成errors.Error，或参数用[]byte却传string，Go 不做隐式转换 - 大小写问题：
Read()和read()是两个方法；首字母小写的方法对外不可见，无法被接口识别
什么时候该用接口？看这三点再决定
接口不是越多越好。滥用会导致抽象过度、调试困难、性能损耗（接口调用有间接跳转开销）。建议只在以下场景引入：
- 需要统一处理多种类型（如日志输出支持
os.File、net.Conn、bytes.Buffer，都实现io.Writer） - 函数/方法参数需支持灵活替换（如测试中注入 mock，生产中用真实 DB client）
- 模块间定义清晰边界（如存储层只暴露
Store接口，上层不依赖具体是 Redis 还是 BoltDB） - 反例：只为单个类型定义仅被自己用的接口，纯属增加冗余
最常被忽略的一点：接口的生命周期应由使用方（调用者）定义，而不是实现方。换句话说，接口应该出现在“想怎么用”的地方，而不是“我有什么”的地方。
