中介者模式在Go中通过结构体、接口和组合实现，用ChatRoom等具体中介者封装对象交互，避免紧耦合；同事对象仅依赖Mediator接口，通过Notify通信，支持灵活替换与测试。
在 Go 语言中，中介者模式（Mediator Pattern）不是靠继承或接口强制实现的“框架式”设计，而是通过一个中心化的协调者（Mediator）来封装多个对象（Colleague）之间的交互逻辑，从而避免对象间直接引用和紧耦合。Go 没有类和继承，但完全可以用结构体、接口和函数组合自然地表达这一思想——关键是把“谁和谁通信”的决策从参与者中抽离出来，交给一个明确的中介者负责。
定义清晰的 Mediator 接口与具体实现
先抽象出中介者行为：它需要能接收消息、识别发送方/接收方、并触发相应处理。不依赖具体类型，只依赖约定好的方法签名。
例如：
type Mediator interface {
Notify(sender interface{}, event string, data interface{})
}
type ChatRoom struct {
users map[string]User
}
func (c *ChatRoom) Notify(sender interface{}, event string, data interface{}) {
switch event {
case "join":
c.broadcast(sender, "new user joined")
case "message":
c.broadcast(sender, data.(string))
}
}
func (c *ChatRoom) broadcast(exclude interface{}, msg string) {
for _, u := range c.users {
if u != exclude {
u.Receive(msg)
}
}
}
这里 ChatRoom 是具体中介者，它不关心用户具体是什么类型，只通过 User 接口的 Receive 方法通信。
立即学习“go语言免费学习笔记（深入）”；
让协作对象只依赖 Mediator 接口，不互相引用
每个“同事”（如 User）持有 Mediator 的引用，但不持有其他同事的引用。它的所有对外动作都通过中介者中转。
定义同事接口：
type User interface {
Send(event string, data interface{})
Receive(msg string)
SetMediator(m Mediator)
}
具体实现只需关注自身职责：
type ConcreteUser struct {
name string
mediator Mediator
}
func (u *ConcreteUser) Send(event string, data interface{}) {
u.mediator.Notify(u, event, data) // 不知道谁会响应，只通知中介者
}
func (u *ConcreteUser) Receive(msg string) {
fmt.Printf("[%s] received: %s\n", u.name, msg)
}
func (u *ConcreteUser) SetMediator(m Mediator) {
u.mediator = m
}
这样，User A 和 User B 完全解耦：A 不需要知道 B 的存在，也不需要调用 B 的任何方法。
用组合代替硬编码，灵活替换中介逻辑
Go 中推荐用字段组合而非继承，所以中介者实例通常作为结构体字段注入。这便于测试和替换——比如开发时用内存版 ChatRoom，上线后换成带 Redis 广播的 DistributedChatRoom。
- 初始化时注入：
user.SetMediator(&ChatRoom{users: make(map[string]User)}) - 单元测试可传入 mock Mediator，断言
Notify是否被正确调用 - 不同场景可实现不同 Mediator：审批流中介者、设备联动中介者、事件总线简化版等
注意 Go 特性带来的实践差异
Go 没有构造器重载或自动生命周期管理，所以要注意几点：
- 中介者若需维护状态（如用户列表），确保并发安全——加
sync.RWMutex或用sync.Map - 避免循环引用：User 持有 Mediator，Mediator 又持有 User 切片 → 这本身没问题，但释放资源时需主动清理（如登出时从中介者中移除）
- 不用为“松耦合”过度抽象：如果只有两个对象且通信极简单，直接传函数回调可能比引入 Mediator 更轻量
中介者模式的价值不在“用了设计模式”，而在于当交互规则变复杂（比如加权限校验、消息过滤、异步分发、日志审计）时，你只需修改中介者，所有同事对象保持不变。
