不能让user直接遍历users切片发消息，因会破坏中介者模式解耦本质，导致逻辑分散、重复代码、无法支持私聊、同名覆盖、类型扩展困难；应由mediator统一调度。
为什么不能让 User 直接遍历 users 切片发消息
直接在 User.Send 里写个 for range users 看似简单，实则破坏中介者模式本质——这不是解耦，是把转发逻辑分散到每个同事对象里。一旦要加审计日志、限流判断或离线缓存，就得改所有 User 类型的 Send 方法，重复代码爆炸。
- 私聊功能根本没法做：切片没索引，
to == "alice"没法快速定位目标*User - 同名用户注册会覆盖：用
[]User存值类型，user1 == user2可能误判，导致消息跳发 - 新增 BotUser 或 AdminUser 时，所有已有
Send都得补类型断言或接口转换
Mediator 接口该定义成 Send(from, to, msg string) 还是 Send(event interface{})
推荐用字符串三元组：Send(from, to, msg string)。小项目里塞 interface{} 纯属自找麻烦，Go 的类型安全优势瞬间清零。
-
event要定义结构体、序列化/反序列化，调试时还得打日志看字段，不如直接打印from + "→" + to + ": " + msg - 私聊查人：
to != ""就去c.users[to]找指针；广播就遍历map[string]*User，跳过from自己即可 - 想扩展消息类型？加个
type字段就行，比如Send("alice", "", '{"type":"join","user":"bob"}')，前端自己解析
注册时机不对，u.mediator 为 nil 导致 panic 怎么防
最常见 panic 不是并发冲突，而是 User.Send 时 u.mediator 还是 nil——因为忘了调 room.Register(u)，或者注册发生在初始化之后、首次 Send 之前。
- 防御写法：在
User.Send开头加if u.mediator == nil { log.Warn("user not registered"); return } - 更稳妥：用构造函数强制绑定，如
NewChatUser(name, room)，不提供无参构造 - 别依赖“连接建立后再注册”：HTTP handler 里才注册，但心跳 goroutine 已经启动并尝试
Send，竞态+panic 双杀
ChatRoom 广播时怎么避免给 sender 自己发消息
不是靠 user != sender 做判断，这个在值接收器或多次 New 后极易失效；必须用业务标识，比如用户名。
立即学习“go语言免费学习笔记（深入）”；
- 注册时用
map[string]*User，key 是user.Name，确保可查可重名校验 - 广播循环里写
if name != from { target := c.users[name]; target.Receive(msg) } - 私聊分支也走同一套路由：只要
to在 map 里存在，就只推给那一个*User，不用改任何收发逻辑
