Golang中介者模式实现聊天室广播消息路由

本文深入剖析了在Go语言中实现中介者模式构建聊天室时的关键设计决策与常见陷阱，强调必须由Mediator统一处理消息路由而非让User直接遍历用户列表，从而真正实现解耦、避免重复逻辑、支持私聊与扩展；主张采用简洁清晰的字符串三元组接口Send(from, to, msg string)，配合以用户名为键的map索引结构，并通过构造函数强制绑定中介者、前置nil检查等防御性手段杜绝panic，最终揭示：看似简单的广播与路由，其健壮性与可扩展性根本取决于注册机制、索引设计和判断依据的严谨选择。

为什么不能让 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 后极易失效；必须用业务标识，比如用户名。

• 注册时用 map[string]*User，key 是 user.Name，确保可查可重名校验
• 广播循环里写 if name != from { target := c.users[name]; target.Receive(msg) }
• 私聊分支也走同一套路由：只要 to 在 map 里存在，就只推给那一个 *User，不用改任何收发逻辑

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Golang中介者模式实现聊天室广播消息路由》文章吧，也可关注golang学习网公众号了解相关技术文章。