go中中介者模式不依赖继承而靠接口和组合实现，核心是“谁持有谁、谁调用谁”；应避免同事类强引用中介者，改用闭包、回调或事件注册被动接入，并区分命令流与事件流合理使用channel。
中介者模式在 Go 里为什么不用类继承也能实现
Go 没有传统面向对象的继承机制，所以没法靠「抽象中介者 + 具体中介者」那一套 UML 图里的写法。但它的接口（interface{}）和组合能力，反而让中介者更轻量——关键不是“谁继承谁”，而是“谁持有谁、谁调用谁”。
常见错误是硬套 Java/C# 写法，比如试图定义一个 Mediator 接口然后让所有同事类都依赖它，结果发现同事之间还是得互相传参、强引用中介者实例，通信路径没真正收敛。
- 真正该做的：把中介者设计成纯函数式协调器，同事对象只暴露
Notify()或HandleEvent()这类方法，内部逻辑由中介者统一调度 - 同事对象不保存对中介者的引用，而是通过闭包、回调或事件注册方式“被动接入”
- 避免在同事结构体字段里直接嵌入
*Mediator—— 这会制造循环依赖，也违背松耦合本意
用 channel 实现松耦合中介者时的典型阻塞问题
很多人一想到“解耦通信”，立刻用 chan 做消息总线，但很快遇到 goroutine 卡死、消息丢失或 panic：send on closed channel。
根本原因不是 channel 用错了，而是没区分「命令流」和「事件流」：命令需要响应，事件只需广播；前者适合带缓冲的 channel + 显式应答，后者更适合 select + default 防阻塞。
立即学习“go语言免费学习笔记（深入）”；
- 别用无缓冲 channel 让同事直接
mediator.events —— 一旦没人接收就永久阻塞 - 给事件 channel 加缓冲（如
make(chan Event, 16)），并在中介者启动 goroutine 消费，用select { case 避免积压 - 如果同事需要确认执行结果，改用
func(Event) error回调，而不是等待 channel 返回值
当多个模块都要注册到同一中介者时，如何避免重复注册或竞态
比如用户模块、订单模块、通知模块都调用 mediator.Register(UserHandler{})，但没做类型检查或去重，导致同个事件被处理两次，或者 map 并发写 panic。
Go 的运行时不会帮你校验注册唯一性，这事必须手动兜底。
- 注册表用
sync.Map替代普通map，尤其当注册/注销发生在不同 goroutine 时 - 用接口的指针地址（
fmt.Sprintf("%p", handler)）或自定义ID() string方法做 key，别用反射名（reflect.TypeOf(h).Name()）—— 同名不同实例会冲突 - 提供
Unregister()并确保它幂等：注销不存在的 handler 不 panic，也不报错
中介者不该承担业务逻辑，但 Go 里容易越界写成“上帝对象”
你写了个 OrderMediator，里面开始处理库存扣减、发 Kafka、更新 Redis 缓存……这已经不是中介者，是业务编排层了。问题在于：测试难、复用差、职责模糊。
中介者的边界很朴素：只转发、只转换、只协调顺序。真正的业务动作，应该交给独立的 service 或 usecase 包。
- 中介者方法里只出现
userSvc.Create()、notify.Send()这类调用，绝不出现if stock - 参数传递用 DTO（如
type OrderCreatedEvent struct { OrderID string; UserID string }），而不是直接传*Order实体——防止同事对象误改共享状态 - 如果发现中介者文件超过 200 行、import 超过 5 个业务包，大概率该拆了
最难把握的是“协调时机”：什么时候该由中介者触发下一步，什么时候该让上游自己决定。这个分寸没有银弹，只能靠日志埋点 + 一次上线后看调用链路是否清晰。一旦发现 A → B → C 的链路里，B 总是机械转发，那 B 就该消失了。
