Go中中介者模式不用class和继承，因Go无类与继承机制；应以结构体承载协调逻辑，用函数字段或方法注入行为，同事仅弱引用中介者，避免循环依赖与过度耦合。
中介者模式在 Go 里为什么不用 class 和继承
Go 没有类、没有继承、也没有 abstract 关键字，所以传统 UML 里的 Mediator 抽象类和 Colleague 基类无法直接翻译。强行用接口模拟抽象类，反而会让协作逻辑散落在各处，失去中介者“集中协调”的本意。
更自然的做法是：用一个结构体承载协调逻辑，用函数字段或方法接收具体行为，同事对象只保留对中介者的弱引用（如 *Mediator 或函数类型）。
- 同事不持有其他同事的引用，只认得中介者
- 中介者持有所有需要协调的组件（可以是 struct 字段、map、或切片）
- 避免循环导入：把中介者定义放在独立包，或与核心业务逻辑同层
如何定义可复用的 Mediator 结构体
中介者不是模板，而是针对具体协作场景定制的协调器。比如聊天室、订单状态同步、UI 组件联动——每种场景下，“谁通知谁”“什么条件下转发”都不同。
典型结构包含三部分：被协调对象的注册容器、事件分发逻辑、以及可注入的响应函数。
立即学习“go语言免费学习笔记（深入）”；
type ChatRoom struct {
users map[string]func(string) // 用户名 → 接收消息的回调
}
func (c *ChatRoom) Register(name string, handler func(string)) {
c.users[name] = handler
}
func (c *ChatRoom) Broadcast(sender, msg string) {
for name, h := range c.users {
if name != sender {
h("[" + sender + "] " + msg)
}
}
}
-
users是 map 而非 slice：便于按用户名快速查找/移除 - handler 类型为
func(string)：解耦具体用户实现，调用方自己决定怎么处理消息 - 不暴露
users字段：防止外部绕过Broadcast直接调用
同事对象如何安全持有中介者引用
同事对象（比如 User）不能直接依赖具体中介者类型，否则会提高耦合度。推荐两种轻量方式：
- 用函数字段替代结构体字段：
onMessage func(string)，由中介者在注册时注入 - 若需双向通信（如用户主动发言），则持有一个指向中介者的指针：
mediator *ChatRoom，但仅调用其公开方法
错误写法示例：mediator MediatorInterface —— Go 中接口应由调用方定义，而非中介者强推。
type User struct {
name string
onMessage func(string) // 收到消息时执行
mediator *ChatRoom // 需要发言时用
}
func (u *User) Send(msg string) {
if u.mediator != nil {
u.mediator.Broadcast(u.name, msg)
}
}
func (u *User) Receive(msg string) {
if u.onMessage != nil {
u.onMessage(msg)
}
}
注意：onMessage 和 mediator 不同时必需；根据协作方向选择其一即可。
什么时候不该用中介者模式
中介者容易变成“上帝对象”，尤其当所有状态变更都塞进一个结构体里时。以下情况建议跳过中介者：
- 只有两个对象交互，且逻辑简单 → 直接互相调用更清晰
- 协作规则随业务频繁变化 → 把逻辑写死在
Mediator里会导致频繁修改，不如用事件总线（如github.com/ThreeDotsLabs/watermill） - 需要跨进程/跨服务协调 → 单机内存结构无法满足，应交由消息队列或状态机服务
真正值得上中介者的，是那些「对象数量中等（3–8 个）、交互关系密集、且生命周期基本一致」的模块，比如表单校验组件组、游戏内 NPC 行为调度器。
