接口哲学：Go接口的隐式实现，如何用接口解耦业务逻辑与基础设施

说实话，我见过太多Go项目，代码写得跟Java似的。

明明Go的接口是隐式实现的，很多人偏要搞个接口工厂、注册中心，把简单的事情搞复杂了。今天咱们聊聊接口的本质——它到底该怎么用，才能让业务逻辑和基础设施真正解耦。

一、隐式实现：Go接口的灵魂

先看个例子。你定义一个接口：

type Storage interface {
    Save(key string, data []byte) error
    Load(key string) ([]byte, error)
}

在Java里，你得写个 implements Storage。在Go里呢？

type LocalFileStorage struct {
    basePath string
}

func (l *LocalFileStorage) Save(key string, data []byte) error {
    // 写入本地文件
    return os.WriteFile(filepath.Join(l.basePath, key), data, 0644)
}

func (l *LocalFileStorage) Load(key string) ([]byte, error) {
    return os.ReadFile(filepath.Join(l.basePath, key))
}

看到了吗？没有 implements，没有 Storage 关键字。只要方法签名对上，它就自动实现了接口。

我个人习惯把接口定义在使用方，而不是实现方。为什么？因为调用者才知道自己需要什么行为。

二、业务逻辑与基础设施的解耦实战

我在项目中遇到过这样一个场景：用户服务需要存储数据，但不确定用MySQL还是Redis。

传统做法是直接依赖具体实现：

type UserService struct {
    db *sql.DB  // 直接依赖MySQL
}

func (s *UserService) GetUser(id int) (*User, error) {
    row := s.db.QueryRow("SELECT * FROM users WHERE id = ?", id)
    // ...
}

这有什么问题？你想想看，如果明天要换成MongoDB，你得改 UserService 的代码。业务逻辑和基础设施完全耦合在一起。

用接口解耦后：

// 在业务层定义接口
type UserRepository interface {
    GetByID(id int) (*User, error)
    Save(user *User) error
}

type UserService struct {
    repo UserRepository  // 依赖接口，不依赖具体实现
}

func (s *UserService) GetUser(id int) (*User, error) {
    return s.repo.GetByID(id)
}

然后在基础设施层实现：

// MySQL实现
type MySQLUserRepo struct {
    db *sql.DB
}

func (r *MySQLUserRepo) GetByID(id int) (*User, error) {
    // MySQL查询逻辑
}

// Redis实现
type RedisUserRepo struct {
    client *redis.Client
}

func (r *RedisUserRepo) GetByID(id int) (*User, error) {
    // Redis查询逻辑
}

在main函数里组装：

func main() {
    db := initMySQL()
    repo := &MySQLUserRepo{db: db}
    service := NewUserService(repo)
    // 业务逻辑完全不知道底层是MySQL
}

三、接口粒度：别太细，也别太粗

接口粒度是个坑。我见过有人把每个方法都定义成一个接口：

type Saver interface {
    Save(key string, data []byte) error
}

type Loader interface {
    Load(key string) ([]byte, error)
}

type Deleter interface {
    Delete(key string) error
}

这太细了。调用者得组合三个接口，代码变得支离破碎。

也见过一个接口包含几十个方法：

type MegaStorage interface {
    Save(key string, data []byte) error
    Load(key string) ([]byte, error)
    Delete(key string) error
    List(prefix string) ([]string, error)
    BatchSave(items map[string][]byte) error
    // ... 还有20个方法
}

这又太粗了。实现方得实现所有方法，哪怕它只需要其中几个。

我个人习惯遵循接口隔离原则：一个接口只包含调用者真正需要的方法。通常3-5个方法最合适。

接口粒度	方法数	适用场景
细粒度	1-2个	函数式接口、回调
中等粒度	3-5个	大多数业务场景
粗粒度	6个以上	尽量避免，除非确实需要

四、空接口 interface{}：慎用

Go 1.18之后有了 any，其实就是 interface{} 的别名。很多人喜欢用 any 来「偷懒」：

func Process(data any) {
    // 然后做类型断言
    switch v := data.(type) {
    case string:
        // ...
    case int:
        // ...
    }
}

嗯，这里要注意。空接口意味着放弃了类型安全。你想想看，如果传入一个 struct{}，你的代码能处理吗？

五、接口组合：Go的优雅之处

Go的接口支持组合，这是它的一个亮点。比如标准库里的 io.ReadWriter：

type ReadWriter interface {
    Reader
    Writer
}

你可以把小的接口组合成大的接口。这样既保持了接口的单一职责，又提供了灵活性。

举个例子：

type Reader interface {
    Read(p []byte) (n int, err error)
}

type Writer interface {
    Write(p []byte) (n int, err error)
}

type Closer interface {
    Close() error
}

// 组合成需要的接口
type ReadWriteCloser interface {
    Reader
    Writer
    Closer
}

调用者只需要声明自己需要的组合：

func CopyAndClose(dst Writer, src Reader, closer Closer) error {
    // 只依赖 Writer 和 Reader
    // 但需要关闭时，传入 Closer
}

六、测试：接口解耦的最大受益者

接口解耦后，测试变得异常简单。你可以轻松地写 mock：

type mockUserRepo struct {
    users map[int]*User
}

func (m *mockUserRepo) GetByID(id int) (*User, error) {
    user, ok := m.users[id]
    if !ok {
        return nil, errors.New("not found")
    }
    return user, nil
}

func TestUserService_GetUser(t *testing.T) {
    repo := &mockUserRepo{
        users: map[int]*User{
            1: {ID: 1, Name: "Alice"},
        },
    }
    service := NewUserService(repo)
    
    user, err := service.GetUser(1)
    // 测试逻辑
}

不需要启动数据库，不需要连接网络。测试跑得飞快。

七、总结：接口的哲学

说白了，Go的接口哲学就一句话：定义行为，而不是定义类型。

你不需要告诉别人「我是什么」，你只需要告诉别人「我能做什么」。这就是隐式实现的精髓。

用接口解耦业务逻辑和基础设施，本质上是在代码里划了一条清晰的线：

• 业务层：定义接口，只关心「做什么」
• 基础设施层：实现接口，只关心「怎么做」

这条线划好了，你的代码就能轻松应对变化。换数据库？换缓存？换消息队列？改一行 main 函数就够了。

嗯，这就是接口的力量。下次写代码时，不妨问问自己：这个依赖真的需要具体类型吗？换成接口会不会更好？