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