1. 接口作为类型：方法集合
当你刚开始编程时，很自然会这样想：“我有数据，那我就创建一个 struct，然后到处传递这个 struct。” 在小程序里这确实可行。但随着代码增长，会出现两个令人不快的习惯：把函数和具体类型绑定在一起（结果就是无法复用），以及把不必要的细节带到不需要它们的地方。
Go 中的接口就是一种表达方式：“我不关心你是什么，我只关心你能做什么。” 这就像插座：你不需要知道发电站内部是怎么运作的；只要插头符合标准，吹风机就能通电。接口就是代码里的这种“标准”：消费者所期望的一组方法。
如果简短而严格地说，Go 中的接口是一个列出方法签名的类型。不是字段。不是“数据”。只有方法。
从历史上看，接口一直就是这样被理解的：作为“一组方法”，而且这依然是日常编程中最有用的理解方式。
接口声明语法
在我们开始把接口应用到这个迷你应用之前，先看看基础语法。它和 struct 很像，只不过内部放的是方法。
package main
type Greeter interface {
Greet() string
}
这里 Greeter 是一个接口类型。它表示：“任何能调用 Greet() 并返回 string 的东西都可以。”
接口不能要求字段
一个非常重要的点，最初会让新手不太适应（但后来会救你一命）：不能通过接口访问字段，因为接口关注的是行为，而不是数据结构。
也就是说，如果你有：
type User struct {
Name string
}
并且 var g Greeter = User{Name: "Anna"}，那么你就不能写 g.Name。因为 Greeter 只“承诺”了方法 Greet，并没有承诺存在 Name 字段。这不是“Go 的限制”，而是一个根本理念：接口应该保护使用者不必知道实现细节。
2. 隐式实现：Go 中没有 implements
当人们从 Java/C#/TypeScript 进入 Go 时，常常会下意识寻找关键字 implements。但 Go 里没有这个关键字。Go 的意思是：“如果某个类型拥有所需的方法，那它就符合。” 就这么简单。
为什么这很方便：
- 实现方不必“知道”自己实现了某个接口；
- 可以从“消费者”的角度添加新的接口，而无需修改旧类型；
- 耦合更少，因此变更时更不痛苦。
小例子：类型会自动满足接口
package main
import "fmt"
type Greeter interface {
Greet() string
}
type User struct {
Name string
}
func (u User) Greet() string {
return "你好，" + u.Name
}
func main() {
var g Greeter = User{Name: "Anna"} // User 满足 Greeter
fmt.Println(g.Greet()) // 你好，Anna
}
注意：我们并没有写过“User implements Greeter”。编译器自己检查了：方法 Greet() string 存在，签名也匹配——所以一切正常。
“签名匹配”意味着“字面完全匹配”
Go 在这一点上非常严格。如果接口要求：
type Closer interface {
Close() error
}
而你写的是：
func (x File) Close() { /* ... */ }
那就不是实现。即使从语义上看你是在关闭文件。签名不同：没有返回 error。对编译器来说，这是另一个方法。
4. 示例：任务列表和格式化接口
让我们继续同一个应用主线（就像我们在前面的讲座里做的那样）：我们有任务（Task），并把它们打印出来。现在我们要加入一种能力：用不同方式打印任务，而不重写整套输出逻辑。这就像给同一个角色换衣服：数据没变，“外观”变了。
数据模型 Task
package main
type Task struct {
ID int
Title string
Done bool
}
目前还没有任何“接口化”的东西——只是一个普通结构体。
“谁会格式化任务”的接口
现在定义一个契约：我们需要某个对象，能够把 Task 转换成字符串。
package main
type TaskFormatter interface {
Format(t Task) string
}
这是一个非常小的接口：只有一个方法。而这正是好事。小接口更容易实现，也更容易理解。
实现 1：简单格式化器
package main
import "fmt"
type PlainFormatter struct{}
func (PlainFormatter) Format(t Task) string {
status := " "
if t.Done {
status = "x"
}
return fmt.Sprintf("[%s] %d: %s", status, t.ID, t.Title)
}
注意这个技巧：PlainFormatter 是一个空结构体。这完全正常！有时我们并不需要保存状态，只需要行为。
实现 2：“调试”格式化器
package main
import "fmt"
type DebugFormatter struct{}
func (DebugFormatter) Format(t Task) string {
return fmt.Sprintf("Task{ID=%d, Title=%q, Done=%v}", t.ID, t.Title, t.Done)
}
现在我们拥有了同一个接口的两种不同实现。
依赖接口的打印函数
关键部分来了：打印任务列表的函数根本不需要知道传进来的是什么格式化器。
package main
import "fmt"
func PrintTasks(tasks []Task, f TaskFormatter) {
for _, t := range tasks {
fmt.Println(f.Format(t)) // 按格式化器的决定进行打印
}
}
这个函数是接口的“消费者”。它并不关心内部是什么：PlainFormatter、DebugFormatter，或者以后你再加的任何其他实现。
在 main 中使用
package main
func main() {
tasks := []Task{
{ID: 1, Title: "Buy milk", Done: false},
{ID: 2, Title: "Fix bug", Done: true},
}
PrintTasks(tasks, PlainFormatter{})
// [ ] 1: Buy milk
// [x] 2: Fix bug
PrintTasks(tasks, DebugFormatter{})
// Task{ID=1, Title="Buy milk", Done=false}
// Task{ID=2, Title="Fix bug", Done=true}
}
而这正是你第一次真正感受到接口“味道”的地方：同样的业务逻辑（PrintTasks）可以配合不同的行为实现工作。
接口作为扩展点：添加新行为
如果你不使用接口，扩展通常会变成这样：“再加一个 if，再加一个 switch，再加一个标志位，再加一个分支。” 代码会慢慢变成一串圣诞彩灯般的条件分支。
接口提供了另一种风格：基础逻辑接收接口，而扩展通过添加实现契约的新类型来完成。这就像 LEGO：你不是把积木融掉重做，而是直接拼接新的模块。
例如，你想只打印任务标题。
package main
type TitleOnlyFormatter struct{}
func (TitleOnlyFormatter) Format(t Task) string {
return t.Title
}
就这样——不需要修改 PrintTasks。
5. 标准库中的接口
非常有必要意识到，接口并不是什么“给架构师看的高级主题”。它是 Go 的基础机制，标准库就是建立在它之上的。你其实已经见过接口，只是不一定意识到而已。
error 是一个接口
Go 里的 error 结构极其简单：要让某个类型“成为错误”，它必须拥有 Error() string 方法。
小例子：
package main
import "fmt"
type ValidationError struct {
Field string
Msg string
}
func (e ValidationError) Error() string {
return fmt.Sprintf("%s: %s", e.Field, e.Msg)
}
func main() {
var err error = ValidationError{Field: "title", Msg: "empty"}
fmt.Println(err.Error()) // title: empty
}
在这个例子中，ValidationError 通过“方法”满足了 error 接口。没有注册、没有继承，也没有什么神秘仪式。
fmt.Stringer
fmt.Stringer 接口是“我能漂亮地转成字符串”的契约：方法是 String() string。
让我们让 Task 自己能漂亮地打印出来。
package main
import "fmt"
func (t Task) String() string {
status := " "
if t.Done {
status = "x"
}
return fmt.Sprintf("[%s] %d: %s", status, t.ID, t.Title)
}
之后，fmt.Println(t) 会使用 String()（如果该类型满足 fmt.Stringer）。这又是一个例子：标准库通过接口“接管”行为。
6. 直观理解：依赖关系与 struct 的对比
示意图：“消费者”依赖接口，而不是实现
为了把这个概念固定下来，最好把它看成一张图。它的含义是：函数 PrintTasks 只认识接口 TaskFormatter。至于实现可以有很多个。
flowchart LR
A["PrintTasks(tasks, f TaskFormatter)"] --> I["TaskFormatter
Format(Task) string"]
I --> P["PlainFormatter"]
I --> D["DebugFormatter"]
I --> T["TitleOnlyFormatter"]
从心理上说，这会让代码轻松很多：主逻辑不会被格式化细节塞满。
表格：接口 vs 结构体
有时候，大脑会习惯性地把接口当成“另一个结构体”。让我们清楚地区分一下：
| 比较项 | |
|
|---|---|---|
| 描述什么 | 数据（字段）+ 可以有方法 | 行为（只有方法） |
| 是否可以保存状态 | 可以，在字段里 | 不可以（接口本身没有字段） |
| 是否可以通过字面量创建值 | 可以：Task{...} | 不能直接创建，只能有一个接口类型变量，往里放具体值 |
| 主要用途 | 建模实体 | 代码各部分之间的契约 |
7. 常见错误
错误 1：试图通过接口访问字段。
这是经典错误：你把 User 赋值给一个接口类型变量，然后突然想写 x.Name。但接口并没有承诺有 Name 字段，它只承诺了方法。正确做法要么是在接口里添加方法（如果这真的是契约），要么在你需要具体字段的地方别用接口，要么通过方法来设计数据访问。
错误 2：“签名几乎一样”，于是以为应该能工作。
Go 不会“按语义猜测”。如果接口要求 Format(Task) string，而你写成了 Format(*Task) string 或 Format(Task) (string, error)，那就是另一个方法。匹配必须是字面上的：名字不重要，但参数和返回值很重要。
错误 3：为了“以防万一”把接口做得太大。
新手很想做一个“万能接口”，一次性塞进 10 个方法，觉得这样“以后肯定够用”。实际结果往往相反：任何想“符合”它的类型都必须实现这 10 个方法，即使其中 9 个对它来说毫无意义。最好从最小契约开始，就像我们的 TaskFormatter，只有一个方法。
错误 4：把接口和实现混淆，试图“创建接口”。
接口不是可以像 interface{...}{...} 那样“初始化”的具体东西（那样不行）。被初始化的是具体类型（比如 PlainFormatter{}），而接口变量只是一个盒子，你往里放的是一个符合条件的具体类型值。
错误 5：以为接口永远都必须使用。
接口是强大的工具，但不是必需品。如果你只有一个实现，且看不到第二个实现，有时候直接传具体类型、不要把代码复杂化反而更简单。只有当接口真的能简化依赖、把“需要什么”和“怎么实现”分开时，它才有价值，就像任务格式化这个例子一样。
GO TO FULL VERSION