Go接口是“已满足”的事实而非契约，值/指针接收者决定实现关系，interface{}需类型断言，接口组合是方法并集，用var _ I = (*T)(nil)可编译期验证实现，窄接口更易复用。
Go 的接口不是“要实现”的契约，而是“已经满足”的事实——只要方法签名完全匹配，编译器就认可你实现了接口。这点不理解，后续所有多态、依赖注入、测试 mock 都会卡在第一步。
为什么 func (t T) Method() 和 func (t *T) Method() 不能互换实现同一个接口
这是最常踩的坑：方法接收者类型（值接收者 vs 指针接收者）直接决定类型是否满足接口。
- 如果接口要求
Method()是指针接收者，那只有*T类型能赋值给该接口变量，T值类型不行；反之亦然 - 常见错误现象：
cannot use t (type T) as type Interface in assignment: T does not implement Interface (Method method has pointer receiver) - 根本原因：Go 中
T和*T是两个不同的类型，方法集不同；值类型的方法集只包含值接收者方法，指针类型的方法集包含值+指针接收者方法 - 解决建议：若结构体有状态变更（如字段赋值），优先用指针接收者；若纯计算且结构体小，可用值接收者；但一旦接口定义了某接收者形式，所有实现必须严格一致
interface{} 看似万能，但一用就丢类型信息
空接口能接任意值，但取出来时必须靠类型断言或类型切换，否则无法调用原类型方法。
- 直接对
interface{}变量调用方法会报错：cannot call method on v (variable of type interface{}) - 类型断言写法：
v.(string)（失败 panic）或v, ok := v.(string)（安全写法） - 性能影响：每次断言都涉及运行时类型检查，高频场景（如循环内）应避免无谓断言
- 典型误用：把一堆
interface{}放进 slice 后逐个断言——不如一开始就用泛型或具体接口约束
接口组合不是继承，是方法签名的并集
嵌入接口（如 type ReadWriter interface{ Reader; Writer }）只是语法糖，本质是展开所有被嵌入接口的方法签名，不引入任何类型关系。
立即学习“go语言免费学习笔记（深入）”；
- 没有父子类概念，
ReadWriter不是Reader的子类型，也不能向上转型 - 冲突检测严格：若两个嵌入接口含同名方法但签名不同（如参数类型不同），编译直接报错
- 组合后仍需完整实现所有方法——不能只实现
Reader部分就认为满足ReadWriter - 设计建议：组合接口前先确认业务语义是否真需要“同时可读可写”，避免为组合而组合
用 _ Interface = (*T)(nil) 提前验证接口实现
这个惯用写法能在编译期暴露“本该实现却漏实现”的问题，比运行时报错更早发现缺陷。
- 写在包级变量位置：
var _ Speaker = (*Dog)(nil)，强制编译器检查*Dog是否满足Speaker - 不占用运行时资源，只参与类型检查
- 注意：必须和接口要求的接收者类型一致——若接口方法是
func (d *Dog) Speak()，就得用(*Dog)(nil)，用Dog{}会失败 - 团队协作中建议每个实现类型都加一行，尤其当接口定义在其他包时，避免因接口更新导致隐性不兼容
接口的威力不在定义得多，而在用得准——一个两三个方法的窄接口（如 io.Writer）比动辄五六个方法的大接口更容易被复用、实现和测试。别为了“抽象”而抽象，先想清楚谁调用、怎么替换、哪里会变。
