Beego聊天室核心是解决WebSocket稳定性问题：升级失败因响应头污染和跨域限制，多房间隔离需绑定room字段到Subscriber，clients并发读写须用sync.RWMutex保护。

Beego 实现聊天室，核心不是“能不能”，而是“WebSocket 怎么不崩”——upgrader.Upgrade 失败、clients 并发读写 panic、消息广播漏发或错发到错误 room，这三类问题占了线上调试的 80%。

WebSocket 连接升级失败：检查 upgrader 配置和响应头

Beego 的 Controller 默认会写入 Content-Type 和其他响应头，而 gorilla/websocket.Upgrader.Upgrade 要求 ResponseWriter 必须“干净”。一旦提前写入任何内容（比如 this.ServeJSON() 或 this.Render()），就会报 http: multiple response.WriteHeader calls 或静默断连。

• upgrader.CheckOrigin 必须显式设置，否则默认拒绝非同源请求（前端在 localhost:3000 访问 localhost:8080 就算跨域）
• 不要在 Get() 方法里调用 this.TplName 或 this.Render()；WebSocket 路由应单独配置，不走模板渲染流程
• 推荐写法：

  var upgrader = websocket.Upgrader{
      CheckOrigin: func(r *http.Request) bool { return true },
      ReadBufferSize:  1024,
      WriteBufferSize: 1024,
  }

多房间隔离失效：room 字段必须绑定到每个 Subscriber 实例

很多实现把 room 放在全局 map 或广播消息体里解析，但没校验接收方是否属于该房间——结果 A 房间发的消息被 B 房间用户收到。

Beego框架 2.3.5

Beego框架 2.3.5 版本源码包下载，适合关注表单空值、函数注释名和 nil 返回值修复的 Go Web 开发者。

下载

• Subscriber 结构体中必须包含 room string 字段，并在连接建立时从 URL query 或 WebSocket handshake 中提取（例如 this.GetString("room")）
• 广播逻辑不能只遍历 clients map，必须对每个 client.room == targetRoom 做判断
• 避免用 json.Unmarshal 解析广播消息再取 room 字段——性能差且易出错；房间信息应作为连接元数据存在内存里，而非每次反序列化

并发读写 clients map 导致 panic

Beego 的 Controller 方法默认在 goroutine 中执行，而 map 不是并发安全的。多个连接同时 subscribe 或 unsubscribe 会触发 fatal error: concurrent map read and map write。

• 必须用 sync.RWMutex 包裹 clients map 的所有读写操作
• subscribe 和 broadcast channel 只负责传递事件，真正增删 clients 的逻辑要放在 manager goroutine 内部统一处理
• 别在 writePump 或 readPump 里直接操作 clients；它们只管收发，状态变更走 channel + mutex

最常被跳过的点：没有给每个 Subscriber 的 messages channel 设置缓冲区，导致写入阻塞后整个 writePump 卡死，后续消息全丢——务必初始化为 messages: make(chan []byte, 32)，数值按业务吞吐预估。