如何在Golang中实现基础的消息推送_Golang WebSocket消息推送示例

正确做法是分离连接管理与消息分发：维护客户端连接池，通过 channel 或 map 管理活跃连接，另启 goroutine 监听广播通道，由 HTTP 接口、定时任务等外部事件触发向指定或全体客户端推送。

用 gorilla/websocket 实现基础消息推送，核心不是“连上就发”，而是“连上后能被外部触发推送”——比如 HTTP 接口调用、定时任务或业务事件触发。直接在 WebSocket handler 里写死 WriteMessage 只能回显，无法做到“服务端主动推”。

为什么不能只靠 handleConnections 循环读写？

单纯在连接处理函数里 for { conn.ReadMessage(); conn.WriteMessage(...) } 只能实现回显或点对点 echo，无法响应外部事件（如管理员发公告、订单状态更新）。真正的推送必须解耦：连接管理 + 消息分发分离。

• 常见错误现象：http.HandleFunc("/ws", ...) 里没启动广播 goroutine，导致 broadcast channel 无人监听，broadcast 永远阻塞
• 关键设计点：必须用一个全局 chan（如 broadcast）作为消息中转站，再由独立 goroutine 拉取并遍历 clients 发送
• 性能影响：若不加缓冲，make(chan string) 是无缓冲 channel，一旦某个 client 写失败卡住，整个广播会停摆；建议用带缓冲的 make(chan []byte, 100)

upgrader.CheckOrigin 不设为 true 就连不上？

开发阶段不放开跨域，浏览器前端用 new WebSocket("ws://localhost:8080/ws") 会直接报 Connection closed before receiving a handshake response。这不是协议错误，是 gorilla/websocket 默认拒绝非同源请求。

• 正确做法：明确允许跨域，但别用 return true 上线——应校验 r.Header.Get("Origin") 是否在白名单内
• 调试时可临时写成：CheckOrigin: func(r *http.Request) bool { return r.Header.Get("Origin") == "http://localhost:3000" || r.Header.Get("Origin") == "" }
• 注意：某些代理（如 Nginx）可能不透传 Origin 头，此时需检查反向代理配置

如何从 HTTP 接口触发 WebSocket 推送？

这是“推送”的刚需场景：比如收到 POST /api/push，把消息发给所有在线用户。不能在 HTTP handler 里直接遍历 clients 并 WriteMessage，因为 clients 是 map，而 *websocket.Conn 非并发安全，且写操作可能阻塞。

• 安全做法：HTTP handler 只往 broadcast channel 发消息，由已存在的 handleMessages() goroutine 统一处理
• 示例接口逻辑：

  func pushHandler(w http.ResponseWriter, r *http.Request) {
      var req struct{ Msg string }
      json.NewDecoder(r.Body).Decode(&req)
      broadcast <- []byte(req.Msg) // 注意：这里发的是 []byte，不是 string
      w.WriteHeader(http.StatusOK)
  }

• 容易踩的坑：如果广播逻辑里用 client.WriteJSON(msg)，但 msg 是 string 类型，会 panic；统一用 []byte 或封装结构体更稳

真正难的不是“怎么发”，而是“发的时候连接还健在吗”。每个 *websocket.Conn 都要配心跳（PingHandler）、超时控制（SetReadDeadline）和异常捕获，否则 clients map 里会堆积大量已断开却未清理的连接，广播时反复报 use of closed network connection ——这个细节，90% 的入门示例都漏掉。