结构体指针接收者和值接收者不能混用，因为t和t是两个不同类型，方法集不重叠；若接口方法要求t接收者，则只有*t能实现，t值传入会编译失败。
Go 接口不是“写个 implements 就完事”的抽象类，而是编译器自动检查的隐式契约——只要类型实现了接口里所有方法签名，它就满足该接口，无需任何声明。
为什么结构体指针接收者和值接收者不能混用？
方法接收者类型决定了它属于哪个方法集：(*MyStruct) 和 MyStruct 是两个不同的类型，它们的方法集不重叠。
- 如果接口定义的是
func (s *MyStruct) Read(p []byte) (n int, err error)，那只有*MyStruct类型能实现它；传入MyStruct{}会编译失败，报错类似MyStruct does not implement Reader - 常见陷阱：数据库封装时，
sql.Rows的Close()是指针接收者，但你误用值类型包装，导致接口无法满足 - 安全做法：对可能修改字段、涉及资源管理（如
io.Reader、sql.Rows）或字段较大时，统一用指针接收者；只读小结构体可考虑值接收者，但要保持整个包内风格一致
interface{} 怎么安全取值？
interface{} 能存任何值，但它是“黑盒”——没有方法，也不暴露类型。直接调用原类型方法会编译失败，必须还原为具体类型。
- 错误写法：
v.Length()（v是interface{}）→ 编译报错：v.Length undefined (type interface {} has no field or method Length) - 推荐写法：用类型断言
s, ok := v.(string)，再判断ok；避免 panic - 多类型分支用
switch v := i.(type)更清晰，比嵌套if易读且不易漏 case - 反射
reflect.ValueOf(v).MethodByName("Foo")虽然可行，但性能差、类型信息丢失、错误难调试，仅限泛型不可用的极少数场景
如何避免 nil 接口陷阱？
接口变量底层是两个字：类型指针 + 数据指针。只有二者都为 nil，接口才真正为 nil。
- 典型问题：
func do() error { var e *MyError; return e }返回的是(*MyError, nil)—— 类型非空，接口不为nil，导致if err != nil意外进入分支 - 调试技巧：用
fmt.Printf("%#v", err)查看底层结构，比fmt.Println(err)更准 - 修复方式：要么返回具体零值（如
return nil），要么显式判空：if e != nil { return e }，再补return nil - mock 测试时尤其要注意：fake 实现若返回了非
nil指针（哪怕指向空结构体），接口变量就不等于nil
最小接口设计为什么关键？
接口粒度直接影响可测试性、可维护性和耦合度。一个函数只依赖 GetUser(id int) (*User, error)，就别塞进 Exec()、BeginTx() 等无关方法。
- 上帝接口（如
type DB interface{ Query(), Exec(), Close(), Ping() }）导致 mock 成本高、职责不清、变更牵一发而动全身 - 按需定义小接口：
type UserReader interface{ GetUser(id int) (*User, error) }，让*sql.DB或*gorm.DB通过简单包装实现它 - 组合优于继承：用
type ReadWriter interface{ Reader; Writer }复用已有接口，而不是重复声明所有方法 - 接口应由调用方定义（“client-owned interface”），而非实现方——谁用，谁定契约
最难的不是写出接口语法，而是在调用链中始终守住接口的边界：当 handler 开始往 service 接口里加日志、缓存、指标方法时，那个接口就已经在悄悄失去抽象意义了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
