go接口是隐式满足的契约，由调用方按需定义最小接口，依赖编译器检查方法集匹配；值/指针接收者影响赋值合法性；小接口组合优于大接口，避免暴露实现细节。
Go 里的接口不是“要实现”的契约，而是“只要方法签名对得上，就自动算数”的事实。它不靠 implements 声明，只靠编译器在赋值或传参时检查方法集是否完整匹配——这点决定了你设计接口时，必须从使用方视角出发，而不是想着“这个结构体将来可能被谁用”。
接口定义必须由调用方决定
很多人一上来就给自己的 struct 定一堆方法，再包一层 interface，结果发现别人根本没法复用。真正合理的做法是：先写函数签名，看它需要什么行为，再反推定义最小接口。
-
io.Reader存在，是因为io.Copy需要一个能Read([]byte) (int, error)的东西；不是因为有人想“抽象出读取能力” - 如果你写了个
func Process(data Source) error，那Source接口就该只含GetData() ([]byte, error)，别加Close()或Reset() - 第三方类型（比如
strings.Reader）能直接传给io.Copy，正是因为它们没为io.Reader写过一行实现声明，只提供了对应方法
值接收者 vs 指针接收者影响接口赋值合法性
编译器检查接口满足性时，会把接收者类型当作方法签名的一部分。这意味着 func (s MyStruct) Read(...) 和 func (s *MyStruct) Read(...) 是两个完全不同的方法，不能互相替代满足同一接口。
- 如果接口要求
Read([]byte) (int, error)，而你只实现了指针接收者版本，那么MyStruct{}字面量无法直接赋值给该接口变量，会报错：MyStruct does not implement X (Read method has pointer receiver) - 反过来，若你只实现了值接收者版本，那
*MyStruct也能满足该接口（因为 Go 允许指针自动解引用调用值接收者方法），但值类型本身没问题 - 常见踩坑：测试时用
MyStruct{}直接传参，生产环境却用&MyStruct{}，结果行为不一致——本质是方法集不同导致的运行时差异
小接口优于大接口，组合优于继承
Go 没有继承，但支持接口组合。一个臃肿的 EverythingDoer 接口既难实现，也难 mock，更破坏单一职责。
- 优先拆成
Reader、Writer、Closer这类单职责接口，再按需组合：type ReadWriter interface { Reader; Writer } - 避免在接口里暴露实现细节，比如
GetConn() net.Conn或SetTimeout(d time.Duration)—— 这会让使用者被迫了解底层结构 - 标准库中
http.ResponseWriter就是个反例：它混入了Flush()、Hijack()等非核心行为，导致很多 mock 实现不得不补一堆空方法
最难把握的其实是“什么时候该定义新接口”。它不该出现在 struct 定义阶段，而应出现在你第一次需要抽象掉具体类型、又不想耦合到其实现细节的那个函数签名里。一旦定义，就别轻易往里加方法——加一个，所有实现者都得改。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
