Go接口解耦核心是契约前置、职责收敛、依赖单向：使用方定义最小行为契约接口，如UserEmailGetter；依赖注入构造函数显式传入实现；桥接模式应对双维度变化，如Notifier接口解耦消息类型与通知渠道。
Go语言中利用接口解耦模块依赖，核心不是“用接口代替具体类型”，而是通过**契约前置、职责收敛、依赖单向**来切断编译期强耦合。它不靠框架，也不靠运行时魔法，靠的是设计时的明确约定。
接口必须由使用方定义
谁调用，谁定义接口。比如订单服务需要查用户邮箱，就在 order/ 包里写：
type UserEmailGetter interface { GetEmailByID(ctx context.Context, id int64) (string, error) }- 用户服务只需实现这个接口，无需导入订单包
- 订单包也不依赖用户服务的任何结构体或内部逻辑
- 这样避免了“为复用而共享接口”导致的接口膨胀和隐式耦合
只暴露最小必要方法
接口不是功能清单，而是当前场景下**刚好够用的行为契约**：
- 不要把
Close()、Config()、Start()塞进业务接口 - 数据库操作接口只留
GetUserByID、SaveUser等真实被调用的方法 - 多一个方法，就多一分实现负担；少一个字段，就少一处测试干扰
- 命名体现用途，如
PaymentNotifier比PaymentService更清晰
依赖注入配合接口传递实现
构造函数是解耦落地的关键入口：
立即学习“go语言免费学习笔记（深入）”；
- 业务结构体用接口字段接收依赖，例如
type OrderService struct { emailer UserEmailGetter } - 初始化时传入具体实现：
NewOrderService(&httpEmailClient{})或NewOrderService(&mockEmailer{}) - 测试时直接替换，不改业务逻辑代码，也不动外部资源
- 避免全局变量或 init 函数隐式初始化，确保依赖显性、可控、可追踪
用桥接模式应对双维度变化
当系统存在两个独立变化方向（如“消息类型 × 通知渠道”），适合用桥接：
- 定义
Notifier interface { Send(content string) error }作为实现层契约 - 告警服务
AlertService内嵌该接口，不关心具体怎么发 - 运行时自由组合：
NewAlertService(SMSNotifier{})或NewAlertService(EmailNotifier{}) - 新增微信通知？只需实现
Notifier，上层逻辑零修改
