go接口实现多态无需implements，因编译期自动检查方法集是否完全匹配接口签名；接收者类型、大小写、参数及返回值必须严格一致，否则报错“missing method”；空接口无行为约束，真正多态需定义带方法的非空接口并由调用方主导设计。
为什么 Go 的接口不写 implements 就能多态
因为 Go 不需要显式声明实现关系——只要类型方法集完全匹配接口定义，编译器就自动认定它实现了该接口。这不是语法糖，而是类型系统层面的隐式满足判断。
常见错误现象：cannot use xxx as type YYY in argument to func: wrong type for method ZZZ，本质是方法签名不一致：比如接收者是 *T 却传了 T 值，或参数类型、返回值数量/顺序不对。
- 方法名、参数类型、返回值类型必须逐字匹配（包括是否导出）
- 接收者类型决定“谁”能赋值给接口：
func (t T) M()允许T和*T赋值；func (t *T) M()只允许*T - 空接口
interface{}是特例，任何类型都满足，但失去类型约束，需靠类型断言或反射取回原类型
interface{} 和具体接口在工厂模式里怎么选
用 interface{} 是为了泛型前时代的“任意类型透传”，比如日志函数记录任意输入；但在工厂模式中，它基本没用——工厂要返回的是有行为契约的对象，不是数据容器。
正确做法是定义窄接口，只暴露必需方法。例如日志后端工厂：
type Logger interface {
Info(string)
Error(string)
}
type FileLogger struct{...}
func (f *FileLogger) Info(s string) {...}
func NewLogger(kind string) Logger {
switch kind {
case "file": return &FileLogger{}
case "http": return &HTTPLooker{}
}
panic("unknown logger")
}
- 返回具体接口类型（如
Logger），调用方才能安全调用Info/Error - 若返回
interface{}，调用方必须做类型断言，失去编译期检查，也违背工厂“封装创建逻辑”的本意 - 接口越小越好：
Writer比ReadWriteCloser更易实现、更易 mock
嵌入接口时为什么不能直接调用被嵌入的方法
接口嵌入只是语法糖，用于组合方法集，不提供“继承链”或“向上转型”。比如 type ReadWriter interface { Reader; Writer }，它等价于把 Reader 和 Writer 所有方法平铺列出——没有隐含的 this.(Reader) 自动转换。
典型坑：func f(r io.Reader) { r.Write(...) } 会编译失败，哪怕你传的是 io.ReadWriter 实例，因为 r 的静态类型只是 io.Reader，不含 Write 方法。
- 嵌入不改变变量的静态类型，只影响接口定义本身
- 想调用子集外的方法，必须显式类型断言：
w, ok := r.(io.Writer) - 运行时断言失败（
ok == false）比编译报错更难排查，所以优先按需定义接口，而非依赖嵌入+断言
多态失效的三个隐蔽信号
不是所有看起来像多态的代码都在真正利用多态。以下情况说明你可能白写了接口：
- 接口只有一个实现类型，且长期不会增加新实现——这时接口只是冗余抽象，不如直接用结构体
- 函数参数是接口，但内部立刻做了
switch v.(type)分支处理每个具体类型——这等于放弃多态，退化为手动分发 - 所有实现类型都共享大量字段或逻辑，却没提取公共结构体嵌入——说明该用组合，而不是靠接口硬凑多态
真正健康的多态，是新增一个实现类型后，原有业务逻辑（如 printArea(s Shape)）完全不用改——这点最容易被忽略，也是检验接口设计是否到位的硬标准。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
