17370845950

直接用切片存用户导致私聊失效，因无法按名查人且同名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 里，内存持续上涨。中介者模式不是“写完就跑”，它要求明确谁负责清理引用。