中介者模式在go中通过Struct+Interface+闭包解耦模块，避免类型引用；用channel和统一Event消息实现轻量协调；中介仅路由、转换、缓冲，不承载业务逻辑，确保删除模块时不需修改其他模块导入或构造函数。
中介者模式在 Go 中的核心作用是解耦通信双方
Go 本身没有类继承和接口强制实现机制，但中介者模式依然有效——关键不是“如何模仿 java 写法”，而是用 struct + interface + 闭包或回调函数，把原本直接调用的依赖关系，转为通过一个中间对象协调。真正降低耦合的不是模式本身，而是你是否让模块之间不再持有对方的类型引用。
用 channel 和 interface 实现轻量中介者
Go 的并发模型天然适合中介者：模块不互相调用，而是向中介发送消息、从中介接收响应。避免使用全局变量或单例，每个中介实例应可独立生命周期管理。
- 定义统一消息类型，比如
type Event struct{ Type String; Payload interface{} } - 中介者持有一组
map[string]func(Event)处理器，按Type分发 - 模块只依赖中介的接口（如
Mediator interface{ Notify(Event); register(string, func(Event)) }），不关心具体实现 - 注册时用匿名函数包装模块方法，避免暴露内部结构体字段
type SimpleMediator struct { handlers map[string][]func(Event) } func (m *SimpleMediator) Notify(e Event) { for _, h := range m.handlers[e.Type] { h(e) } } func (m *SimpleMediator) Register(t string, f func(Event)) { m.handlers[t] = append(m.handlers[t], f) }警惕“伪中介者”：别让中介变成上帝对象
常见错误是把所有逻辑都塞进中介者，导致它既处理业务又转发事件，最终比原来更难维护。中介者只做三件事：路由、转换、缓冲（可选）。业务规则仍应在模块内部。
- 不要在中介里写
if e.Type == "order_created" { sendEmail(); updateInventory() } - 不要让中介持有数据库连接、http 客户端等具体依赖
- 如果两个模块通信频率极高（如高频状态同步），考虑是否真需要中介——直接 channel 配对可能更清晰
- 测试中介者时，用 mock handler 替代真实模块，验证事件是否被正确分发
与 Go 生态协同：用 context 和 Error 统一传递上下文
原生 context.Context 和 error 不应被中介者截断。模块发出的 Event 可嵌入 ctx context.Context 字段；中介分发前应检查 ctx.Err() 并跳过已取消操作；所有 handler 返回的 error 应透传回发起方，而不是吞掉或转成 panic。
立即学习“go语言免费学习笔记（深入）”；
耦合度是否真的降低了，不看代码行数，而看当你删掉某个模块时，是否还需要修改其他七八个模块的 import 列表或构造函数参数——中介者存在的唯一意义，就是让这个删除动作变得安静。