中介者模式在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）组合能力。

• 不要让一个 Mediator 同时处理登录、聊天、文件传输——拆成 LoginMediator、ChatMediator 等
• 如果只是临时协调，甚至可用闭包：func() { ... }() 包裹几个局部变量和回调
• 字段用指针而非值，避免复制大结构体；但也要注意 nil panic，初始化检查要到位

真正难的不是写出来，而是判断什么时候该用中介者——当三个以上组件开始互相传参、加条件判断、改一个就要动五个文件时，就是信号。