必须用 map[string]*User 替代 []User，因切片无法 O(1) 查找、值比较不可靠、无法检测重名；注册需校验键存在，Mediator 接口必须带 context.Context 以支持超时与取消。
直接用切片存用户会导致私聊失效，根本原因是缺乏快速索引能力且值比较不可靠；必须改用 map[string]*User，并配合注册校验与上下文支持，否则消息路由会出错、goroutine 会泄漏、测试也难做。
为什么 []User 不能用于真实聊天室
很多初学者照着示例写 ChatRoom{ users []User }，结果私聊发不出、广播漏人、甚至同名用户互相覆盖——这不是逻辑错，是数据结构选错了。
- 切片无法按用户名
O(1)查找目标用户，每次私聊都要遍历，to == ""广播还容易误判 -
User是值类型时，u1 == u2比较的是全部字段，不是身份；两个同名NewUser("Alice")实例会被当成同一人跳过发送 - 没有唯一键，
Register无法检测重名，后注册的同名用户直接覆盖前一个，静默丢失连接
必须用 map[string]*User 并校验重名
指针 + 字符串键是 Go 中最清晰、最安全的用户索引方式。它既避免复制大结构体，又天然支持 nil 判断和地址唯一性。
func (c *ChatRoom) Register(user *User) {
if user == nil {
return
}
if _, exists := c.users[user.Name]; exists {
log.Printf("警告:用户名 %s 已存在", user.Name)
return
}
user.mediator = c
c.users[user.Name] = user
}- 注册前检查
c.users[user.Name]是否已存在，防止覆盖 - 赋值用
*User指针，确保后续user.Receive()修改的是同一实例 - 私聊时直接查
c.users[to]，不存在就返回错误，不兜底、不猜测
Mediator 接口必须带 context.Context
不加 context 的中介者接口看似简洁，但只要消息分发涉及日志写入、HTTP 调用或数据库操作，就会立刻暴露问题：超时无法控制、取消无法响应、goroutine 堆积泄漏。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 标准签名应为：
Send(ctx context.Context, from, to, message string) - 调用方传入带超时的上下文：
u.mediator.Send(context.WithTimeout(ctx, 3*time.Second), u.Name, "Bob", "hi") - 中介者内部对每个接收者启动 goroutine 时，需单独派生子上下文：
ctx, cancel := context.WithCancel(parentCtx); defer cancel()，避免一个卡住拖垮全部
广播与私聊的判断逻辑必须用名字，不用指针比较
常见错误是在 broadcast 循环里写 if u != sender —— 这在值接收器、临时变量或多次 NewUser 场景下必然失效。
func (c *ChatRoom) broadcast(excludeName string, msg string) {
for name, user := range c.users {
if name == excludeName {
continue
}
go func(u *User) {
select {
case <-time.After(5 * time.Second):
log.Printf("用户 %s 接收超时", u.Name)
default:
u.Receive(msg)
}
}(user)
}
}- 永远用
name == excludeName做排除，语义明确、稳定可靠 - goroutine 内部传参用
go func(u *User)显式捕获，避免闭包引用循环变量 - 加简单超时兜底，比无限阻塞更健壮
真正难的不是写出能跑的中介者，而是从第一行注册逻辑开始就守住边界：不接受未注册用户发消息、不假设用户一定在线、不把路由逻辑散落在各个 User 方法里。Go 的中介者模式，本质是一场对“谁掌握通信发起权”的持续确认。
