中介者模式在Go中通过接口定义协调能力，同事对象仅依赖中介者接口并注入实现，所有交互经中介者转发，其内部管理状态与分发逻辑，强调职责分离、松耦合与可测试性。
中介者模式通过引入一个中介对象来封装一系列对象之间的交互，让对象之间不再相互引用，而是通过中介者进行通信。在 Go 语言中，由于没有类继承和接口强制实现的强约束，该模式更侧重于职责分离与松耦合设计，而非严格遵循传统 OOP 实现。
定义清晰的中介者接口
用 interface 明确中介者应提供的协调能力，比如转发消息、触发事件、同步状态等。这能让同事对象（Colleague）只依赖抽象，不依赖具体实现。
- 避免让同事直接调用其他同事的方法，所有跨对象操作都走中介者方法
- 接口方法命名体现意图，如 NotifyUserJoined、BroadcastMessage，而非泛化的 Handle
- 可为不同场景定义多个细粒度接口（如 ChatMediator、RoomManager），避免“上帝中介者”
同事对象只持有中介者接口引用
每个参与协作的结构体（如 User、ChatRoom、NotificationService）仅保存一个中介者接口字段，初始化时注入，不自行创建或查找其他同事。
- 构造函数接收中介者作为参数，体现依赖注入思想
- 同事内部不保存其他同事指针，例如 User 不持有一个 map[string]*User 或 *ChatRoom
- 调用中介者方法时传递必要上下文（如 sender ID、payload），由中介者决定如何分发
中介者内部管理关系与分发逻辑
中介者结构体负责维护同事注册信息（如用户列表、房间映射）、校验权限、转换消息格式、控制广播范围等。它知道“谁在哪儿”“谁能做什么”，但同事对此一无所知。
立即学习“go语言免费学习笔记（深入）”；
- 使用 sync.Map 或 RWMutex 保护共享状态，尤其在并发聊天/通知场景下
- 对敏感操作（如踢人、禁言）做权限检查，把策略逻辑集中到中介者，而非散落在各同事中
- 可结合 channel 或 callback 实现异步通知，避免阻塞发送方
用组合代替硬编码关联
Go 中没有多重继承，但可通过嵌入（embedding）+ 接口组合灵活复用行为。例如，一个 BaseColleague 类型可嵌入通用字段（ID、Mediator）和基础方法（SendToMediator），再被具体类型匿名嵌入。
- 减少重复代码：所有同事都需调用中介者？提取共用字段和方法
- 测试友好：可为中介者接口提供 mock 实现，单独测试同事行为
- 便于演进：新增同事类型只需实现约定方法并注册到中介者，无需修改已有同事代码
不复杂但容易忽略的是：中介者本身不该成为新瓶颈或状态黑洞。保持它轻量、专注协调，把业务规则下沉到领域对象或服务层，才能真正降低耦合，提升系统可维护性。
