如何使用Golang实现中介者与消息分发_Golang中介者模式通信方法

直接用切片存用户导致私聊失效，因无法按名查人且同名User实例==比较误判；应改用map[String]*User索引，注册时校验重名；Mediator接口须带context.Context以支持超时与取消。

为什么直接用 map 存用户会导致私聊失效？

很多初学者照搬示例写 ChatRoom{ users []User }，结果发现私聊功能根本没法加——因为切片里没有用户标识，无法按名字查人。更隐蔽的问题是：如果多个 User 实例同名（比如测试时反复 New），== 比较会误判为同一人，导致消息被跳过。

• 必须用 map[string]*User 或 map[uintptr]*User 做索引，推荐前者，语义清晰
• 注册时检查重复名，避免覆盖：

  func (c *ChatRoom) register(user *User) {     if _, exists := c.users[user.Name]; exists {         log.Printf("警告：用户名 %s 已存在", user.Name)         return     }     user.mediator = c     c.users[user.Name] = user }

• 广播时用 user.Name != sender.Name 判断，而不是 user != sender——后者在值接收器调用中可能失效

Mediator 接口要不要带 context.Context？

要，尤其当消息分发涉及 I/O（如写日志、调用下游 API）或需超时控制时。不加 context 的接口看似简洁，但一旦中介者逻辑变重，就丧失取消和截止能力，goroutine 泄漏风险陡增。

• 标准写法是：Send(ctx context.Context, message string, sender Colleague)
• 同事调用时传入自己的上下文：u.mediator.Send(context.WithTimeout(ctx, 5*time.Second), msg, u)
• 中介者内部需对每个 Receive() 调用做单独上下文派生，避免一个卡住拖垮全部：

  for _, u := range c.users {     if u == sender { continue }     go func(user *User) {         select {         case <-ctx.Done():             return         default:             user.Receive(message)         }     }(u) }

如何让 User 不持有 Mediator 实现体？

硬编码依赖 *ChatRoom 是最常见耦合源头。同事对象应只依赖 Mediator 接口，且初始化时不暴露中介者具体类型。

• 构造函数不接收 *ChatRoom，而收 Mediator 接口：

  func NewUser(name string, m Mediator) *User {     return &User{ Name: name, mediator: m } }

• 测试时可轻松注入 mock：

  type MockMediator struct{} func (m MockMediator) Send(_ string, _ Colleague) { /* 记录调用 */ }

• 注意：Go 中接口变量本身不包含指针地址信息，所以 u.mediator == nil 检查必须在 Send() 开头做，否则 panic

并发安全的 Send 怎么做才不拖慢性能？

给整个 Send() 方法加 sync.RWMutex 锁是最省事但最差的选择——所有发消息操作串行化，聊天室一热闹就卡顿。

立即学习“go语言免费学习笔记（深入）”；

• 真正需要保护的是 users 映射的读写，不是消息转发逻辑本身
• 用 sync.RWMutex 仅包裹 map 操作，Receive() 调用放开并发：

  func (c *ChatRoom) Send(ctx context.Context, message string, sender Colleague) {     c.mu.RLock()     defer c.mu.RUnlock()     for _, u := range c.users {         if u == sender { continue }         // 此处不加锁，允许并发 Receive         u.Receive(message)     } }

• 若需支持运行时动态增删用户，写操作（Register/Unregister）用 mu.Lock()，读操作用 RUnlock()，保持读多写少的性能优势

实际项目里最容易被忽略的是生命周期管理：短命的 User（比如 http 请求级会话）没主动注销，却长期挂在 ChatRoom 的 map 里，内存持续上涨。中介者模式不是“写完就跑”，它要求明确谁负责清理引用。