如何使用Golang实现中介者与消息分发_Golang中介者模式通信方法_网络技术

直接用切片存用户导致私聊失效，因无法按名查人且同名User实例==比较误判；应改用map[string]*User索引，注册时校验重名；Mediator接口须带context.Context以支持超时与取消。

为什么直接用 `map` 存用户会导致私聊失效？

很多初学者照搬示例写 ChatRoom{ users []User }，结果发现私聊功能根本没法加——因为切片里没有用户标识，无法按名字查人。更隐蔽的问题是：如果多个 User 实例同名（比如测试时反复 New），== 比较会误判为同一人，导致消息被跳过。

必须用 map[string]*User 或 map[uintptr]*User 做索引，推荐前者，语义清晰

注册时检查重复名，避免覆盖：

func (c *ChatRoom) Register(user *User) {
    if _, exists := c.users[user.Name]; exists {
        log.Printf("警告：用户名 %s 已存在", user.Name)
        return
    }
    user.mediator = c
    c.users[user.Name] = user
}

广播时用 user.Name != sender.Name 判断，而不是 user != sender——后者在值接收器调用中可能失效

`Mediator` 接口要不要带 `context.Context`？

要，尤其当消息分发涉及 I/O（如写日志、调用下游 API）或需超时控制时。不加 context 的接口看似简洁，但一旦中介者逻辑变重，就丧失取消和截止能力，goroutine 泄漏风险陡增。

标准写法是：Send(ctx context.Context, message string, sender Colleague)
同事调用时传入自己的上下文：u.mediator.Send(context.WithTimeout(ctx, 5*time.Second), msg, u)

中介者内部需对每个 Receive() 调用做单独上下文派生，避免一个卡住拖垮全部：

for _, u := range c.users {
    if u == sender { continue }
    go func(user *User) {
        select {
        case <-ctx.Done():
            return
        default:
            user.Receive(message)
        }
    }(u)
}

如何让 `User` 不持有 `Mediator` 实现体？

硬编码依赖 *ChatRoom 是最常见耦合源头。同事对象应只依赖 Mediator 接口，且初始化时不暴露中介者具体类型。

构造函数不接收 *ChatRoom，而收 Mediator 接口：

func NewUser(name string, m Mediator) *User {
    return &User{ Name: name, mediator: m }
}

测试时可轻松注入 mock：

type MockMediator struct{}
func (m MockMediator) Send(_ string, _ Colleague) { /* 记录调用 */ }

注意：Go 中接口变量本身不包含指针地址信息，所以 u.mediator == nil 检查必须在 Send() 开头做，否则 panic

并发安全的 `Send` 怎么做才不拖慢性能？

给整个 Send() 方法加 sync.RWMutex 锁是最省事但最差的选择——所有发消息操作串行化，聊天室一热闹就卡顿。

立即学习“go语言免费学习笔记（深入）”；

真正需要保护的是 users 映射的读写，不是消息转发逻辑本身

用 sync.RWMutex 仅包裹 map 操作，Receive() 调用放开并发：

func (c *ChatRoom) Send(ctx context.Context, message string, sender Colleague) {
    c.mu.RLock()
    defer c.mu.RUnlock()
    for _, u := range c.users {
        if u == sender { continue }
        // 此处不加锁，允许并发 Receive
        u.Receive(message)
    }
}

若需支持运行时动态增删用户，写操作（Register/Unregister）用 mu.Lock()，读操作用 RUnlock()，保持读多写少的性能优势

实际项目里最容易被忽略的是生命周期管理：短命的 User（比如 HTTP 请求级会话）没主动注销，却长期挂在 ChatRoom 的 map 里，内存持续上涨。中介者模式不是“写完就跑”，它要求明确谁负责清理引用。

# go # golang # 为什么 # String # 构造函数 # register # 指针 # 接口 # 切片 # nil # map # 并发 # 对象 # http # 的是 # 自己的 # 多个 # 一人 # 问题是 # 怎么做 # 挂在 # 不加 # 就跑 # 最容易

相关栏目：【网站优化151355 】【网络推广146373 】【网络技术251813 】【 AI营销90571 】