不能让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 之前。

Golang Spf13 Viper

Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。

下载

• 防御写法：在 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，不用改任何收发逻辑

复杂点往往藏在注册和索引设计里——map 键选什么、nil 检查放哪、判断依据用值还是标识，这几个地方定下来，后面加功能基本不动骨架。