Go中无法照搬UML类图的中介者模式，因其缺乏类继承且易引发循环导入、nil panic和并发安全问题；应改用接口+回调函数+chan等原生机制解耦，同事仅暴露事件钩子，中介者通过注册回调协调交互。
Go 语言没有类和继承，也不支持传统面向对象意义上的“中介者模式”实现（比如用抽象中介者 + 具体中介者 + 各种同事类继承体系），但可以用接口、函数值、结构体组合和通道等原生机制达成等效效果——关键是解耦对象间的直接引用，让交互通过一个中心协调者转发。
为什么 Go 里不能照搬 UML 类图的中介者模式
标准中介者模式依赖：同事对象持有中介者引用、中介者持有所有同事引用、同事之间不直接通信。Go 中若强行模拟，容易出现循环导入（colleague.go 引 mediator.go，后者又引回前者）、指针管理混乱、测试困难等问题。
实际可行的做法是：用 interface{} 或更具体的回调函数类型替代“同事抽象类”，用结构体字段存储可变行为，用 chan 或闭包控制时序和响应边界。
常见错误现象：
立即学习“go语言免费学习笔记（深入）”；
- 把
*Mediator塞进每个同事结构体，导致初始化顺序错乱或 nil panic - 在中介者方法里直接调用同事的导出方法，又反过来让同事调中介者，形成隐式循环依赖
- 用全局变量存中介者实例，破坏可测试性和并发安全性
用函数字段 + 接口实现轻量中介协调
核心思路：同事不持有中介者，只暴露事件钩子（如 OnMessage、OnChange）；中介者通过设置这些钩子来注入逻辑，同事触发时自动通知中介者，中介者再决定调用谁。
适用场景：UI 组件联动（如按钮点击更新列表+禁用输入框）、微服务间弱一致性通知、配置变更广播等不需要强状态同步的交互。
示例中，User 和 Logger 都实现 Notifier 接口，ChatMediator 不持有它们的指针，而是接收它们注册的回调函数：
type Notifier interface {
Notify(event string, data interface{})
}
type ChatMediator struct {
onUserJoin func(username string)
onMessage func(sender, msg string)
}
func (m *ChatMediator) RegisterUserJoin(f func(string)) {
m.onUserJoin = f
}
func (m *ChatMediator) RegisterMessage(f func(string, string)) {
m.onMessage = f
}
type User struct {
name string
notify func(event string, data interface{})
}
func (u *User) Send(msg string) {
u.notify("message", map[string]string{"sender": u.name, "msg": msg})
}
func main() {
mediator := &ChatMediator{}
logger := &Logger{}
user1 := &User{name: "Alice", notify: func(e string, d interface{}) {
if e == "message" {
data := d.(map[string]string)
mediator.onMessage(data["sender"], data["msg"])
}
}}
mediator.RegisterMessage(func(sender, msg string) {
logger.Log(sender + ": " + msg)
if sender == "Alice" && msg == "/ban" {
// 这里可以触发其他协作逻辑，比如通知 moderator
}
})
user1.Send("Hello")
}
用 channel 实现异步中介通信（适合高并发）
当同事间交互有明确生产者/消费者关系，且需解耦执行时机（比如日志写入不阻塞业务逻辑），用 chan 更自然。中介者变成消息路由中心，不主动调用同事，只转发事件。
性能影响：channel 有缓冲开销，但避免了锁和 goroutine 泄漏风险；若用无缓冲 channel，要注意发送方是否可能被阻塞。
关键点：
- 每个同事只向中介者的
input chan发送结构化事件（不要传指针或闭包） - 中介者用
select多路复用，按事件类型分发到不同处理逻辑 - 同事从自己的
output chan读响应，避免中介者反向调用造成耦合
错误典型：在中介者里直接 go colleague.Handle(...)，结果同事结构体未实现并发安全，或 handle 方法 panic 导致整个中介 goroutine 退出。
什么时候该放弃“模式名”，直接用简单函数或 map 注册
如果同事数量固定（≤3）、交互逻辑简单（如 A 改变 → B 更新 → C 刷新）、且生命周期短（如 CLI 工具的一次性流程），硬套中介者反而增加理解成本。
更 Go 的做法是：
- 定义一个协调函数，参数是各组件的接口或函数类型：
func RunChat(ui UI, log Logger, db DB) - 用
map[string]func()存事件处理器，key 是事件名，value 是匿名函数，内部闭包捕获所需依赖 - 测试时直接传 mock 函数，不用构造整套结构体树
复杂点在于：事件命名易冲突、缺乏类型检查、重构时不易发现调用链断裂。这些比“不符合设计模式”更值得警惕。
