go接口是隐式实现的契约，结构体指针实现方法才满足接口因方法集分离；interface{}需类型断言安全取出；应定义最小接口避免“上帝接口”和nil陷阱。
Go 接口不是“要声明才实现”的抽象契约，而是编译器自动识别的隐式匹配——只要类型实现了接口里所有方法，它就满足该接口，无需 implements 或任何关键字。
为什么给结构体指针实现方法才算真正实现接口？
方法接收者类型决定谁能调用、谁被接口接受。如果接口方法签名要求的是 (*MyStruct) Method()，那只有 *MyStruct 类型（而非 MyStruct）能实现它。
- 常见错误：定义了
func (s MyStruct) Read(...)，但接口要求Read(p []byte) (n int, err error)的接收者是*MyStruct—— 编译失败，提示 “MyStructdoes not implement ...” - 根本原因：值接收者和指针接收者在 Go 中属于不同方法集。值类型无法调用指针接收者方法，反之亦然
- 安全做法：对可能修改字段或需保持一致性（如
io.Reader、sql.Rows）的类型，统一用指针接收者；若只读且小结构体，可用值接收者
interface{} 能存一切，但怎么安全取出来？
interface{} 是空接口，底层存了类型和值两部分。直接调用原类型方法会编译报错，必须先还原为具体类型。
- 不安全断言：
v.(string)—— 类型不符时 panic，线上慎用 - 安全断言：
s, ok := v.(string)——ok为false时不 panic，可分支处理 - 多类型判断用
switch v := x.(type)，比嵌套if更清晰 - 别用
reflect绕过类型检查：性能差、难调试、破坏静态类型优势
如何避免“上帝接口”和 nil 判断陷阱？
接口膨胀和 nil 判断失效，往往源于没理解接口变量的二元结构（类型指针 + 数据指针）。
- “上帝接口”表现：一个
Service接口塞了 12 个方法，但某个 handler 只用其中 2 个 —— 导致 mock 复杂、违反单一职责 - 正确做法：按调用方需要定义最小接口，例如
UserGetter只含GetByID(id int) (*User, error) - nil 陷阱：函数返回
var e *MyError，即使e == nil，接口变量仍是(*MyError, nil)，不等于nil - 调试技巧：用
fmt.Printf("%#v", err)查看接口底层结构，比fmt.Println(err)更准
最难的不是写接口，是在调用链中维持接口粒度与实际依赖的一致性——比如 HTTP handler 依赖的 service 接口，一旦开始往里加日志、缓存、指标方法，就说明职责已扩散，该拆了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
