Go语言中介者模式解决的核心问题是多个模块因频繁直接调用导致的网状强耦合，引发修改牵连多处、测试困难、复用性差；应通过统一事件通知接口、显式注册、ID化管理及并发安全分发来解耦。
Go 语言中介者模式解决的核心问题是：**多个模块/组件之间因频繁直接调用而形成的网状强耦合，导致修改一处牵连多处、测试困难、难以替换或复用**。
为什么不用直接调用？——常见错误现象
很多初学者在实现用户通知、订单-库存联动、GUI 组件响应等逻辑时，会这样写：
orderService.Process() → inventoryService.Decrease() → notifyService.SendSMS()
这看似清晰，实则埋下三个隐患：
- 循环依赖风险：
orderService必须 importinventoryService和notifyService，后者又可能反过来依赖前者 - 无法单独测试：
orderService的单元测试必须 mock 所有下游，一改全测 - 扩展成本高：新增「积分发放」模块？得改
orderService.Process里三处地方
中介者接口怎么定义才不踩坑？
关键不是功能多，而是职责单一、参数通用。别写 SendOrderCreatedEvent() 这种具体方法，要用事件驱动抽象：
立即学习“go语言免费学习笔记（深入）”；
type Mediator interface {
Notify(event string, data interface{}, sender interface{})
}
这样设计的好处：
Skill Weave Chains — 技能链路由引擎
下载
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
-
event字符串可路由（如"order.created"、"user.login"），便于后期加过滤或分发策略 -
data interface{}兼容任意结构体，避免为每个事件定义新方法 -
sender interface{}不绑定具体类型，同事对象无需导出自身结构体给中介者包
反例：定义 SendToUser(user *User, msg string) —— 立刻把中介者和 User 类型耦死，且无法支持异步、重试、日志追踪等横切逻辑。
同事对象注册与通信的实操要点
同事（Colleague）不是被动接收者，它要主动注册、持有中介者引用，并通过统一入口发消息：
type User struct {
name string
mediator Mediator // 接口，非具体类型
}
func (u *User) OnOrderPlaced(orderID string) {
u.mediator.Notify("order.placed", map[string]string{"id": orderID}, u)
}
注意三点：
- 注册必须显式调用（如
mediator.Register(u)），不能靠构造函数自动完成——否则无法控制注册时机（比如组件初始化未完成就发事件） -
Notify的sender参数务必传真实指针（u），方便中介者做发送者过滤（比如群聊不回自己） - 同事内部不保存其他同事引用，
Receive方法应只处理业务逻辑，不做转发或状态同步
中介者内部如何安全分发事件？
最易错的是并发与生命周期管理。别用 map[interface{}]*Colleague 直接存指针——goroutine 并发注册/注销时容易 panic。推荐方案：
- 用
sync.RWMutex保护注册表，读多写少场景下性能足够 - 注册时用唯一 ID（如
uuid.NewString()）替代指针作为 key，避免 GC 后指针失效 - 事件分发用
for range遍历前先 copy 切片，防止遍历时被其他 goroutine 修改底层数组
示例关键片段：
type ChatRoom struct {
mu sync.RWMutex
users map[string]Colleague // key 是 uuid，不是 *User
}
func (c *ChatRoom) Notify(event string, data interface{}, sender interface{}) {
c.mu.RLock()
users := make([]Colleague, 0, len(c.users))
for _, u := range c.users {
users = append(users, u)
}
c.mu.RUnlock()
for _, u := range users {
if u != sender { // 注意：这里需同事实现 == 比较，或用独立 ID 字段判断
go u.Receive(event, data) // 异步发，避免阻塞
}
}
}
真正难的不是写通逻辑，而是想清楚哪些逻辑该留在同事里（如订单校验）、哪些该交给中介者（如广播顺序、失败重试、跨模块事务补偿）。边界模糊时，优先让中介者只做“调度”，不做“业务”。
