接口不是为了“面向对象”，而是为了边界
很多人第一次看到 Go 接口，会下意识把它和 Java、PHP 或 TypeScript 的接口放在一起理解。它们确实都能描述一组方法，但 Go 接口最特别的地方是隐式实现：一个类型不需要声明自己实现了某个接口，只要方法集匹配，就自动满足接口。
这让 Go 接口非常轻。你可以在需要抽象的地方定义接口，而不是在实现类型诞生时就提前规划一整套继承关系。换句话说，Go 接口更像调用方写下的一份需求清单：我不关心你具体是什么，只要你能做这几件事。
接口最适合表达边界：业务服务不想关心邮件具体怎么发送，处理器不想关心数据到底存在内存还是数据库，测试不想真的调用外部支付网关。只要边界清楚，接口就能让代码更可替换、更容易测试。
一个最小接口
先看一个简单例子：
type Notifier interface {
Send(to string, message string) error
}
任何类型只要有这个方法，就实现了 Notifier：
type EmailNotifier struct {
From string
}
func (n EmailNotifier) Send(to string, message string) error {
fmt.Printf("send email from %s to %s: %s\n", n.From, to, message)
return nil
}
使用接口：
func welcomeUser(notifier Notifier, email string) error {
return notifier.Send(email, "欢迎注册")
}
调用：
notifier := EmailNotifier{From: "noreply@example.com"}
if err := welcomeUser(notifier, "xiaolin@example.com"); err != nil {
fmt.Println(err)
}
EmailNotifier 没有写 implements Notifier，但它拥有 Send(to string, message string) error 方法，所以自动满足接口。这就是隐式实现。
接口应该由使用方定义
初学者容易在实现旁边先定义一个大接口：
type UserRepository interface {
Create(user User) error
Update(user User) error
Delete(id int64) error
FindByID(id int64) (User, error)
FindByEmail(email string) (User, error)
List() ([]User, error)
}
如果某个函数只需要按邮箱查用户，却被迫依赖整个接口，就不够清楚：
func login(repo UserRepository, email string) error {
user, err := repo.FindByEmail(email)
if err != nil {
return err
}
fmt.Println(user.Name)
return nil
}
更好的方式是让使用方定义自己需要的最小接口：
type UserFinder interface {
FindByEmail(email string) (User, error)
}
func login(finder UserFinder, email string) error {
user, err := finder.FindByEmail(email)
if err != nil {
return err
}
fmt.Println(user.Name)
return nil
}
这样 login 的依赖非常清楚：它只需要按邮箱查用户，不需要创建、删除或列出所有用户。小接口是 Go 的重要习惯。
结构体满足多个接口很自然
一个类型可以同时满足多个接口，不需要额外声明。
type UserStore struct {
users map[string]User
}
func (s *UserStore) FindByEmail(email string) (User, error) {
user, ok := s.users[email]
if !ok {
return User{}, fmt.Errorf("user not found")
}
return user, nil
}
func (s *UserStore) Save(user User) error {
s.users[user.Email] = user
return nil
}
它同时满足：
type UserFinder interface {
FindByEmail(email string) (User, error)
}
type UserSaver interface {
Save(user User) error
}
这就是隐式实现的好处。实现类型不需要提前知道未来会被哪些接口使用。调用方可以按自己的需求定义接口。
当然，这也意味着方法签名必须完全匹配。参数类型、返回值类型、顺序都要一致。差一个 error 都不算实现。
用接口隔离外部依赖
假设注册用户后要发送欢迎邮件：
type RegisterService struct {
notifier Notifier
}
func NewRegisterService(notifier Notifier) *RegisterService {
return &RegisterService{notifier: notifier}
}
func (s *RegisterService) Register(email string) error {
if email == "" {
return fmt.Errorf("email is required")
}
if err := s.notifier.Send(email, "欢迎注册我们的服务"); err != nil {
return fmt.Errorf("send welcome message: %w", err)
}
return nil
}
RegisterService 不知道邮件怎么发，也不关心将来是否改成短信、站内信或消息队列。它只依赖 Notifier。这就是接口的价值：把“我需要什么能力”和“具体怎么实现”分开。
真实项目里，接口边界通常出现在这些地方：数据库访问、缓存、消息队列、第三方 API、文件系统、时间获取、随机数生成。它们共同特点是：外部环境不稳定，测试时不想真的调用，未来可能替换实现。
测试替身让业务逻辑更容易测
有了接口，可以在测试里写一个假的通知器：
type FakeNotifier struct {
To string
Message string
}
func (f *FakeNotifier) Send(to string, message string) error {
f.To = to
f.Message = message
return nil
}
测试：
func TestRegisterSendsWelcomeMessage(t *testing.T) {
notifier := &FakeNotifier{}
service := NewRegisterService(notifier)
err := service.Register("xiaolin@example.com")
if err != nil {
t.Fatalf("Register() error = %v", err)
}
if notifier.To != "xiaolin@example.com" {
t.Fatalf("notifier.To = %q", notifier.To)
}
}
这个测试不需要真的发邮件，也不需要配置 SMTP。它只验证业务逻辑是否调用了通知能力。接口让测试更轻，也让代码更容易在本地运行。
如果要测试失败路径，可以让假实现返回错误：
type FailingNotifier struct{}
func (FailingNotifier) Send(to string, message string) error {
return fmt.Errorf("network unavailable")
}
这比在测试里模拟真实网络故障可靠得多。
空接口不是万能容器
Go 里 interface{} 可以表示任意类型。新版本里也常写成 any：
func printAny(v any) {
fmt.Println(v)
}
这很灵活，但不要滥用。一个函数如果接收 any，调用者就失去了类型约束，函数内部也常常需要类型断言：
func userName(v any) string {
user, ok := v.(User)
if !ok {
return ""
}
return user.Name
}
如果你明确需要用户，就直接接收 User：
func userName(user User) string {
return user.Name
}
any 适合日志、通用容器、JSON 解码中间状态、框架级扩展点。普通业务代码里，类型越明确越好。
类型断言和类型选择
当你确实拿到接口值，并需要判断具体类型时，可以使用类型断言：
var v any = "hello"
text, ok := v.(string)
if !ok {
fmt.Println("not a string")
return
}
fmt.Println(text)
不要省略 ok：
text := v.(string)
如果类型不匹配，这会 panic。除非你非常确定，否则用 value, ok 更稳。
多个类型判断可以用 type switch：
func describe(v any) string {
switch value := v.(type) {
case string:
return "string: " + value
case int:
return fmt.Sprintf("int: %d", value)
case nil:
return "nil"
default:
return "unknown"
}
}
类型选择适合处理真正多态的数据。但如果业务里到处都是 type switch，可能说明接口设计太宽泛。
接口值里的 nil 陷阱
Go 接口值包含两部分：动态类型和动态值。一个接口只有在两部分都为空时，才等于 nil。这会产生经典坑：
type EmailNotifier struct{}
func (EmailNotifier) Send(to string, message string) error {
return nil
}
func buildNotifier() *EmailNotifier {
return nil
}
func main() {
var notifier Notifier = buildNotifier()
fmt.Println(notifier == nil) // false
}
虽然动态值是 nil 指针，但接口里还有动态类型 *EmailNotifier，所以接口本身不是 nil。调用方法时可能发生 panic。
避免这个问题的办法是：不要把 nil 具体指针塞进接口；构造函数失败时返回 nil, error；使用前在边界处做好校验。
func NewEmailNotifier(config Config) (Notifier, error) {
if config.Host == "" {
return nil, fmt.Errorf("host is required")
}
return &EmailNotifier{}, nil
}
这样调用方拿到的接口要么是可用实现，要么是明确错误。
小结
Go 接口的核心不是“写一个 interface 关键字”，而是把依赖边界表达小、表达准。接口由使用方定义，方法越少越好；实现类型不需要声明实现关系，只要方法匹配即可；接口能隔离外部依赖，也能让测试更轻。
不要把接口当成所有结构体的标配。只有当你需要替换实现、隔离外部系统、降低调用方依赖时，接口才真正有价值。普通数据传递直接用结构体就好。
学会接口后，你会发现 Go 的抽象方式很克制。它不鼓励提前设计庞大体系，而是在边界出现时，用一两个方法把能力描述清楚。这种小而明确的抽象，是 Go 代码长期可维护的重要原因。
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。