中介者模式在Go中通过结构体字段组合与显式委托实现解耦，由中介者统一掌握通信发起权，各组件仅持有中介者指针，避免相互依赖；需警惕上帝对象，应按业务边界拆分小中介者或用闭包临时协调。
中介者模式在 Go 中不靠继承、不靠接口强制约束，而是靠结构体字段组合 + 显式委托来实现解耦；它适合多个组件间交互逻辑复杂但又不想彼此 import 的场景。
用 struct 字段持有所有协作方，而不是让各方互相持有对方
Go 没有“抽象中介者类”，直接定义一个具体结构体，把所有需要通信的组件作为字段嵌入或引用。关键不是“谁继承谁”，而是“谁掌握通信发起权”——中介者必须是唯一能调用多方方法的中心点。
- 避免让
A直接调用B.Do()，改为m.B.Do()，其中m是中介者实例 - 各组件（如
User、ChatRoom）不保存对方指针，只保存中介者指针（*Mediator） - 中介者字段类型可以是具体类型，也可以是 interface（如果需要 mock 或替换实现）
Mediator 方法封装交互逻辑，不暴露内部组件细节
中介者对外提供语义清晰的方法（如 SendMessage(from, to, msg)），内部协调多个组件行为。这些方法不返回底层组件实例，也不暴露字段访问权限。
- 例如：用户发送消息时，不直接操作
chatLog或通知onlineUsers列表，而是调用m.BroadcastMessage(msg) - 广播逻辑里才真正调用
m.logger.Log()和m.notifier.SendToAll() - 这样新增一个
MetricsCollector组件时，只需改BroadcastMessage内部，不改任何用户代码
type Mediator struct {
logger *Logger
notifier *Notifier
chatHistory *ChatHistory
}
func (m *Mediator) BroadcastMessage(msg string) {
m.logger.Log("broadcast", msg)
m.chatHistory.Append(msg)
m.notifier.SendToAll(msg)
}
警惕“中介者变上帝对象”：按职责拆分 Mediator 实现
一个巨型 Mediator 结构体会迅速失控。Go 更推荐按业务边界切分多个小中介者，或者用函数选项（functional options）组合能力。
立即学习“go语言免费学习笔记（深入）”；
- 不要让一个
Mediator同时处理登录、聊天、文件传输——拆成LoginMediator、ChatMediator等 - 如果只是临时协调，甚至可用闭包：
func() { ... }()包裹几个局部变量和回调 - 字段用指针而非值，避免复制大结构体；但也要注意 nil panic，初始化检查要到位
真正难的不是写出来，而是判断什么时候该用中介者——当三个以上组件开始互相传参、加条件判断、改一个就要动五个文件时，就是信号。
