Go语言通过接口实现基于行为契约的轻量多态，无需继承；接口是方法签名集合，不可含字段或实现；类型自动满足接口需方法集完全匹配，注意接收者类型；运行时多态依赖统一接口变量调用不同实现，避免类型判断。
Go 语言中没有传统面向对象的“继承”和“多态”概念，但接口（interface{}）提供了更轻量、更灵活的多态能力——它基于“行为契约”，而非类型关系。只要一个类型实现了接口声明的所有方法，就自动满足该接口，无需显式声明。
如何正确定义一个接口类型
接口是方法签名的集合，定义时只写方法名、参数和返回值，不写实现。关键点在于：方法名首字母大小写决定是否可导出；空接口 interface{} 可接收任意类型；接口本身不能包含字段或嵌套结构。
常见错误是把接口写成带实现的类模板，比如误加 func 关键字在接口内，或试图在接口里定义变量：
- ❌ 错误：
type Reader interface { func Read() []byte }（func关键字多余） - ✅ 正确：
type Reader interface { Read() []byte } - ❌ 错误：
type Logger interface { prefix string; Log(msg string) }（接口不能有字段）
如何让自定义类型“自动满足”接口
Go 不需要 implements 或 extends 声明。只要类型的方法集完整覆盖接口方法（签名完全一致，包括接收者类型），编译器就认可其满足该接口。注意接收者是值还是指针会影响是否满足：
立即学习“go语言免费学习笔记（深入）”；
动态切换AI模型以优化成本与性能。当用户发出“eco mode”、“balanced mode”、“smart mode”或“max mode”等模式指令，或使用“/modes status”查询状态及“/modes setup”配置模式时触发。
- 如果接口方法接收者是
*T，只有*T类型变量能赋值给该接口；T值类型不行（除非显式取地址） - 如果所有方法接收者都是
T，则T和*T都可赋值（Go 自动处理指针解引用） - 示例：
type Speaker interface { Say() string }，type Dog struct{}实现了func (d Dog) Say() string，那么var s Speaker = Dog{}合法；但若实现的是func (d *Dog) Say()，就必须写var s Speaker = &Dog{}
如何用接口实现运行时多态（如策略模式）
典型做法是定义接口作为抽象行为，多个结构体各自实现，再通过统一接口变量调用不同实现。这避免了 switch 或 if-else 判断类型，也利于测试替换（比如用 mock 实现替代真实 HTTP 客户端）。
常见陷阱是忽略接口零值：未初始化的接口变量是 nil，直接调用其方法会 panic；需先判空或确保赋值：
-
var w io.Writer是nil，w.Write([]byte("x"))会 panic - 安全写法：
if w != nil { w.Write(...) }，或从函数返回非 nil 接口（如os.Stdout） - 性能提示：接口变量底层包含类型信息和数据指针，小类型（如
int）装箱后会有内存开销；高频场景慎用接口包装基础类型
为什么 interface{} 不等于“万能类型”，而是一种类型擦除机制
interface{} 是所有类型的公共上层接口，但它不是类型系统里的“根类”。它只是表示“任何类型都满足我”，实际使用时仍需类型断言或反射才能还原原始类型。滥用会导致代码难以维护、丢失类型安全。
- ❌ 过度泛化：
func Process(data interface{})→ 调用前必须v, ok := data.(string)，否则 panic - ✅ 更好设计：
type Processor interface { Process() error }，让调用方自己实现 - 调试技巧：打印
fmt.Printf("%T", x)可看到接口变量背后的真实类型，有助于排查“为什么这个interface{}不能转成map[string]int”之类问题
接口真正的复杂点不在语法，而在于设计时是否真正围绕“行为”建模——不是为了多态而多态，而是当多个类型需要被同一组逻辑消费时，才抽出接口。过早抽象或强行统一不同语义的行为（比如把 Save() 和 Render() 塞进同一个接口），反而会让调用方困惑。
