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

本文深入剖析了在Go语言中实现聊天室系统时如何正确应用中介者模式，强调必须由Mediator统一处理消息路由而非让User直接遍历用户列表，从而避免逻辑分散、重复代码、私聊无法实现、同名用户覆盖及类型扩展困难等典型陷阱；文章指出应采用简洁安全的字符串三元组接口Send(from, to, msg string)，结合map[string]*User索引设计与严格注册时机控制（如构造函数强制绑定、Send前nil防护），确保广播自动过滤发送者、私聊精准投递、未来轻松扩展消息类型——真正把解耦落到实处，让架构骨架稳定、清晰、可演进。

为什么不能让 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，不用改任何收发逻辑

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

本篇关于《Golang中介者模式实现聊天室消息路由》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于Golang的相关知识，请关注golang学习网公众号！