Go语言中介者模式解决了什么问题_Go中介者模式解耦通信方式-Golang

Go语言中介者模式解决的核心问题是多个模块因频繁直接调用导致的网状强耦合，引发修改牵连多处、测试困难、复用性差；应通过统一事件通知接口、显式注册、ID化管理及并发安全分发来解耦。

Go 语言中介者模式解决的核心问题是：**多个模块/组件之间因频繁直接调用而形成的网状强耦合，导致修改一处牵连多处、测试困难、难以替换或复用**。

为什么不用直接调用？——常见错误现象

很多初学者在实现用户通知、订单-库存联动、GUI 组件响应等逻辑时，会这样写：

orderService.Process() → inventoryService.Decrease() → notifyService.SendSMS()

这看似清晰，实则埋下三个隐患：

• 循环依赖风险：orderService 必须 import inventoryService 和 notifyService，后者又可能反过来依赖前者
• 无法单独测试：orderService 的单元测试必须 mock 所有下游，一改全测
• 扩展成本高：新增「积分发放」模块？得改 orderService.Process 里三处地方

中介者接口怎么定义才不踩坑？

关键不是功能多，而是职责单一、参数通用。别写 SendOrderCreatedEvent() 这种具体方法，要用事件驱动抽象：

type Mediator interface {
    Notify(event string, data interface{}, sender interface{})
}

这样设计的好处：

• event 字符串可路由（如 "order.created"、"user.login"），便于后期加过滤或分发策略
• data interface{} 兼容任意结构体，避免为每个事件定义新方法
• sender interface{} 不绑定具体类型，同事对象无需导出自身结构体给中介者包

反例：定义 SendToUser(user *User, msg string) —— 立刻把中介者和 User 类型耦死，且无法支持异步、重试、日志追踪等横切逻辑。