golang如何实现实时通知推送服务_golang实时通知推送服务实现大全-Golang-PHP中文网

应使用 gorilla/websocket 实现 WebSocket 长连接推送，避免轮询；需用 upgrader.Upgrade() 升级连接，读写分离 goroutine，写操作加锁，用 sync.Map + 心跳检测管理连接，推荐 atomic 生成 ID，按场景选 WriteMessage 或 WriteJSON，Nginx 反代须配置三项关键参数。

golang如何实现实时通知推送服务_golang实时通知推送服务实现大全

用 `net/http` + `gorilla/websocket` 做基础长连接推送，别碰轮询

HTTP 轮询（包括短轮询、长轮询）在实时性、连接开销和服务器负载上都远不如 WebSocket。Go 原生 net/http 不直接支持 WebSocket 协议，必须借助标准库外的成熟实现——gorilla/websocket 是当前最稳定、文档最清晰、被大量生产项目验证的选择。

常见错误是试图用 http.HandlerFunc 直接读写 ResponseWriter 模拟“流式推送”，结果触发 HTTP 连接关闭或响应头已发送错误（http: multiple response.WriteHeader calls）。

初始化连接时，务必用 upgrader.Upgrade() 将 HTTP 连接升级为 WebSocket，之后所有通信走 *websocket.Conn
每个连接需单独 goroutine 处理读/写，避免阻塞；写操作必须加锁（conn.WriteMutex.Lock()），因为 WriteMessage 非并发安全
客户端断连后，ReadMessage 会返回 io.EOF 或 *websocket.CloseError，此时应主动 conn.Close() 并清理对应连接状态

`map[uint64]*websocket.Conn` 存连接？小心并发 panic 和内存泄漏

用简单 map 存连接看似直观，但 Go 的原生 map 并发读写会直接 panic（fatal error: concurrent map read and map write）。更隐蔽的问题是：连接断开后若没及时从 map 删除，goroutine 持有 *websocket.Conn 引用，GC 无法回收，连接对象+缓冲区持续占内存。

改用 sync.Map 只解决并发安全，不解决泄漏；必须配合心跳检测（如每 30s conn.WriteMessage(websocket.PingMessage, nil)）+ SetPingHandler 回调来识别失活连接
连接 ID 别硬编码用 int 或 time.Now().UnixNano()，推荐用 atomic.AddUint64(&idSeq, 1) 生成唯一 uint64 ID，避免重复和溢出
实际业务中，连接常需绑定用户身份（如 user_id），建议用二级结构：map[int64][]*clientConn，其中 *clientConn 封装 *websocket.Conn + 心跳时间戳 + 关闭 channel

推送消息用 `conn.WriteJSON()` 还是 `conn.WriteMessage()`？看场景

WriteJSON() 内部调用 json.Marshal() 再传给 WriteMessage()，多一次序列化开销。对高频小消息（如“用户 A 已上线”），直接构造 []byte 或复用 bytes.Buffer 更高效；但若消息结构复杂、字段动态，WriteJSON() 省心且不易错。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

避免在推送前对整个消息体做 json.Marshal() 后再传给 WriteMessage(websocket.TextMessage, data) —— 这等于手动重复 WriteJSON() 的工作
二进制协议（如 Protobuf）推送时，必须用 WriteMessage(websocket.BinaryMessage, data)，且客户端需明确按 Binary 类型接收，否则浏览器会报 Invalid frame header
单条消息超过 64KB 默认限制会触发 websocket: write deadline exceeded，需提前调用 conn.SetWriteDeadline()，或拆分消息（服务端分片 + 客户端拼接）