go接口是隐式实现的行为契约，无需implements声明；结构体方法集完全匹配接口方法签名即自动实现，但接收者类型必须一致，且接口应由调用方定义、保持最小化。
Go 接口不是类型继承，是隐式实现
Go 的接口不靠 implements 或 extends 声明，只要结构体方法集完全满足接口定义的方法签名（名称、参数、返回值），就自动实现了该接口。没显式声明，也没编译错误提示——这是最常被误解的点。
- 如果结构体漏了一个方法，或参数类型写成
*T却只实现了T版本，运行时不会报错，但传给期望该接口的函数时会编译失败，错误信息通常是cannot use ... as ... value in argument to ...: missing method XXX - 方法接收者类型必须一致：接口要求
func (t T) Read(...)，你就不能只实现func (t *T) Read(...)（反之亦然），哪怕逻辑一模一样 - 空接口
interface{}能接收任何值，但用它做参数等于放弃类型约束，后续要靠类型断言或反射操作，容易出 panic
用接口解耦依赖时，定义权要在调用方手里
谁消费接口，谁定义接口。不是“先写好结构体，再套个接口”，而是“先想清楚我要什么行为，再定义最小接口”。
- 错误做法：在数据层定义
type UserRepository Interface { Save(u User) Error; FindByID(id int) (User, error) }，然后让 handler 层直接依赖它——这会让数据层决定业务层能用什么，违反控制反转 - 正确做法：handler 层定义
type UserStorer interface { StoreUser(u User) error }，只声明自己真正需要的能力；数据层的结构体只要实现这个方法，就能注入进来 - 接口越小越好：
io.Reader只有一个Read([]byte) (int, error)，却支撑了整个 I/O 生态；定义type Processor interface { Process() error; Validate() bool; Log() String }往往意味着职责过重，后期难替换
空接口和 any 不是多态的替代品
any 是 interface{} 的别名，它们本身不提供任何行为契约。把多态逻辑退化成 interface{} + 类型断言，等于放弃 Go 接口设计的初衷。
- 常见错误：写一个通用函数
func print(v interface{})，里面一堆if v, ok := v.(string); ok { ... }——这不是多态，是手动 dispatch，且无法静态检查分支覆盖 - 性能上，每次类型断言或反射都带运行时开销；而真正接口调用是间接跳转，开销固定且可预测
- 如果真需要处理多种类型，优先考虑是否能抽象出统一行为接口，比如
type Stringer interface { String() string }，而不是塞进interface{}再硬拆
接口变量的底层结构影响 nil 判断
接口变量不是简单指针，它由两部分组成：动态类型（type）和动态值（data）。只有当二者都为零值时，接口才为 nil。
立即学习“go语言免费学习笔记（深入）”；
- 常见坑：
var w io.Writer = os.Stdout是非 nil；但var w io.Writer = (os.File)(nil)是非 nil（type 是os.File，data 是 nil），此时调用w.Write(...)会 panic，而非静默失败 - 安全写法：不要依赖
w == nil判断可用性，而应在使用前明确初始化，或用指针接收者+判空组合（如if w != nil && w != (*os.File)(nil)太丑，不如重构） - 返回接口的函数，如果内部可能返回未初始化的指针，务必确保返回的是真正的 nil 接口，而不是带 type 的“半空”值
接口的隐式性带来灵活，也藏了判断盲区。最麻烦的永远不是“怎么写接口”，而是“什么时候该把某个行为抽成接口”——这得看调用链路里谁更可能变，谁更该被隔离。