Go interface 应该放在哪一层？为什么更推荐调用方定义小接口

Go 项目里的 interface 不应该先按“数据库层、缓存层、第三方服务层”统一铺开，而应该先看谁真正需要这份能力。多数业务代码里，更稳的做法是让调用方按自己的使用场景定义一个小接口，让具体实现自然满足它。这样依赖方向更清楚，测试替身更简单，后续实现从 MySQL 换成 PostgreSQL、HTTP 客户端或内存实现时，也不必把一堆无关方法一起拖着改。

接口的名字不重要，依赖方向更重要

很多团队刚开始写 Go 分层代码时，会习惯性在 repo 包里放一个 Repository 接口，再写一个 mysqlRepo 实现它。这个写法看起来像“先抽象再实现”，但它有一个容易被忽略的问题：接口由实现方定义，调用方仍然围绕实现方的抽象转。

Go 的接口是隐式满足的。一个类型不需要声明“我实现了某个接口”，只要方法集合匹配，就能被当作该接口使用。这让接口可以非常轻地贴近调用方：订单服务只需要创建订单，就定义一个 OrderCreator；报表服务只需要查询列表，就定义一个 OrderReader。同一个具体仓储可以同时满足多个小接口，而不需要提前知道所有调用方。

这也是 Go 代码评审里常见的判断：接口通常由使用方定义，而不是由实现方预设。真正要关注的不是接口文件放哪个目录好看，而是依赖箭头是否朝着稳定的业务契约。

什么时候真的需要定义 interface

不是所有依赖都要先抽接口。Go 里很多结构体直接传指针就很好，过早抽象会让代码多一层名字，却没有带来可替换性。可以先看三种压力是否存在。

如果这些压力都不存在，先写具体类型通常更简单。等到调用方真的需要隔离、替换或测试时，再把它实际用到的方法抽成小接口，成本并不高。

典型做法：调用方定义自己用到的小接口

假设订单服务只需要创建订单，它不关心仓储是否还能查询、更新、导出或统计。接口就可以定义在订单服务所在包里，名字围绕调用方的动作来写。

package order

import "context"

type Creator interface {
    Create(ctx context.Context, o Order) error
}

type Service struct {
    creator Creator
}

func NewService(creator Creator) *Service {
    return &Service{creator: creator}
}

func (s *Service) Submit(ctx context.Context, o Order) error {
    if err := validateOrder(o); err != nil {
        return err
    }
    return s.creator.Create(ctx, o)
}

具体实现可以在另一个包里：

package mysqlstore

import "context"

type Store struct {
    db *DB
}

func (s *Store) Create(ctx context.Context, o order.Order) error {
    // 写入订单表，省略具体 SQL
    return nil
}

mysqlstore.Store 没有声明自己实现了 order.Creator，但方法匹配，就可以传给 order.NewService。这就是 Go 接口最舒服的地方：调用方定义边界，实现方保持朴素。

反例：为了 mock 提前在实现方造大接口

另一个常见反例，是在实现方包里提前定义一个很大的 OrderRepository，把增删改查、统计、导出、导入全塞进去。最开始只是为了方便测试替身，后来每次业务增加一个方法，所有实现和测试替身都要跟着补。

package repo

type OrderRepository interface {
    Create(ctx context.Context, o *Order) error
    Get(ctx context.Context, id int64) (*Order, error)
    Update(ctx context.Context, o *Order) error
    Delete(ctx context.Context, id int64) error
    Count(ctx context.Context, q Query) (int64, error)
    Export(ctx context.Context, q Query) ([]byte, error)
}

如果订单提交服务只用 Create，它不应该被 Export、Count 这些方法影响。大接口会让调用方承担它不需要的变化，测试替身也会越来越笨重。

更稳的改法不是把大接口再拆成更多“实现方接口”，而是回到调用方：订单提交只要 Creator，订单详情只要 Reader，报表导出只要 Exporter。这些接口可能都由同一个具体类型满足，但每个调用方只看见自己需要的契约。

把接口放错层会带来哪些后果

接口放错层时，短期看起来只是多一个文件，长期会在维护中显形。

• 依赖变宽：一个只需要创建订单的服务，被迫依赖查询、导出、统计等无关方法。
• 测试变重：测试替身必须实现一堆不会被调用的方法，测试代码开始喧宾夺主。
• 演进变慢：实现方接口一改，多个调用方和多个替身都要跟着改。
• 命名变虚：Repository、Manager、Provider 越写越大，很难看出真实用途。
• 边界变暗：代码看似解耦，实际只是把具体依赖换成了一个更大的抽象依赖。

当然，也不是所有实现方接口都错。比如公开 SDK、插件系统、跨团队稳定协议，接口本身就是对外契约，此时需要由提供方设计并维护。关键是不要把这种公共契约的做法，机械搬到每个内部业务包里。

判断清单：评审时看五个问题

代码评审时，可以用下面这五个问题快速判断接口应该放哪里。

一个实用判断是：如果你还没有具体调用场景，就先不要急着定义接口；如果你已经有调用场景，就按调用方需要的最小方法集合定义接口。

相关问题

Go 里接口是不是越小越好？

不是机械越小越好，而是要贴近使用场景。一个方法的接口很常见，但如果调用方天然需要两个或三个方法共同完成任务，也可以把它们放在同一个小接口里。

Repository 接口到底能不能放在 repo 包？

可以，但要看它是不是稳定的对外契约。如果只是某个 service 为了测试数据库调用，通常放在 service 附近更清楚；如果 repo 包就是对多个模块提供统一协议，放在 repo 包也合理。

接口放调用方会不会导致重复定义？

可能会有少量重复，但这种重复通常是健康的。不同调用方需要的能力不完全一样，重复的小接口比共享的大接口更容易演进。只有当重复接口长期完全相同、语义也一致时，再考虑提取公共契约。

具体类型还需要写编译期检查吗？

在关键边界可以写，例如 var _ order.Creator = (*Store)(nil)。它能让实现不匹配时更早暴露，但不要把它当成必须铺满全项目的仪式。

总结

Go 的 interface 更适合从调用方需求里长出来，而不是在实现方提前搭一个抽象层。内部业务代码优先让调用方定义小接口，具体类型自然满足；公开 SDK、插件协议和跨团队稳定边界，再由提供方维护接口契约。判断标准始终是：谁需要这组方法，变化应该影响谁，接口是否让依赖更清楚。