中介者模式在go中应通过接口+组合实现，同事对象不持有中介者指针，仅暴露notify/handle方法；中介者用sync.map存储eventhandler回调，区分命令流（func(command) error）与事件流（带缓冲channel）。

直接用中介者模式解决多对象通信开销，核心不是加一层转发，而是把“谁通知谁、谁响应谁”的路径收束到一个可控点上。Go 里尤其不能照搬 Java 那套继承写法——没有抽象类，也不靠强引用维系关系，关键在接口定义清晰、组合自然、通信流分类明确。

用接口+组合替代继承，同事对象不持有中介者指针

同事对象（比如 User、Order、Notification）只暴露行为方法，如 Notify(event Event) 或 Handle(cmd Command)，内部不存 *Mediator 字段。中介者通过闭包、回调或注册函数接入它们：

• 定义 type EventHandler func(Event) error，同事注册时传入该函数，而非自身实例
• 中介者用 sync.Map 存储 handler，key 用 fmt.Sprintf("%p", &h) 或自定义 ID() string 方法，避免同名类型冲突
• 同事注销时调用 Unregister(id string)，幂等处理：查不到就忽略，不 panic

区分命令流与事件流，channel 使用要分场景

不是所有消息都适合走 channel。盲目用 chan Event 容易卡死或丢消息，根本在于没区分语义：

• 命令流（如 “扣减库存”“生成订单”）需要结果反馈 → 改用 func(Command) error 回调，由中介者同步/异步执行并返回错误
• 事件流（如 “用户已登录”“订单已支付”）只需广播 → 用带缓冲的 channel（make(chan Event, 16)），中介者启 goroutine 消费，配合 select { case e := 防积压
• 绝对不用无缓冲 channel 让同事直接往 mediator.events 写 —— 一旦消费端阻塞或未启动，发送方立刻 hang 住

中介者本身不堆逻辑，只做路由与轻协调

中介者不是“上帝对象”，它的职责是收敛通信入口，而不是包办所有业务判断。复杂协调应下沉：

• 路由规则写成独立函数，如 routePaymentEvent(e PaymentEvent) []string，返回目标 handler ID 列表
• 状态校验、幂等控制、重试策略放在具体 handler 内部，中介者只负责按规则派发
• 跨模块事务（如“下单成功→扣库存→发通知”）用 Saga 模式拆解，中介者只触发第一步，后续靠事件链驱动

注册即生效，但需防竞态与重复

多个模块（用户、订单、风控）并发调用 Register() 时，容易 map 并发写 panic 或重复注册：

• 注册表必须用 sync.Map，或封装读写锁的结构体
• 注册前先检查是否已存在（用 handler 的唯一 ID 查），存在则跳过，不覆盖
• 提供 Replace(id string, h Handler) 供热更新，旧 handler 自动注销