您的位置:首页 >Go语言实现消息推送实战教程
发布于2026-02-03 阅读(0)
扫一扫,手机访问
短轮询适合小规模通知,需用Redis缓存消息并清空已读;SSE需严格设置响应头和flush;WebSocket须处理心跳、超时与重连;微信推送需自动刷新Token并重试。

http.HandleFunc 做短轮询,够用但别硬扛高并发多数内部系统或小规模后台通知(比如运营后台给审核员弹个“新工单来了”),直接用短轮询最省事。它不依赖长连接、不操心重连、浏览器兼容性拉满——IE11 都能跑。
但要注意:messages 用内存 map 存只是演示,真实场景必须换成 Redis 或带过期的本地缓存(如 freecache),否则进程重启消息就丢了;另外别忘了在返回后清空或标记已读,否则用户每次请求都拿到同一堆消息。
setInterval(() => fetch("/poll?user_id=123"), 30000) 控制频率w.Header().Set("Cache-Control", "no-cache"),防止代理缓存响应用户数 / 30,很容易打爆 API 网关handleEvents 实现 SSE 推送时,响应头和流式写入缺一不可SSE 是 Web 场景下最轻量的单向推送方案,比 WebSocket 少一堆连接管理逻辑,适合日志流、状态广播、实时告警等场景。但它不是“发个 response 就完事”,必须严格满足协议要求。
常见失败现象:浏览器控制台报 Failed to load resource: net::ERR_INCOMPLETE_CHUNKED_ENCODING,基本就是响应头漏了、没 flush、或者中途 panic 导致连接中断。
w.Header().Set("Content-Type", "text/event-stream")、w.Header().Set("Cache-Control", "no-cache")、w.Header().Set("Connection", "keep-alive")w.(http.Flusher).Flush(),否则数据卡在缓冲区不下发json.NewEncoder(w).Encode() 直接写,得手动拼 data: {...}\n\n 格式,否则浏览器解析不了WebSocket 适合需要双向通信的场景(比如客服聊天、协同编辑),但 Go 里用 github.com/gorilla/websocket 时,很多人只写了 upgrader.Upgrade 和 conn.ReadMessage,结果压测半小时连接全掉——因为没处理网络抖动、NAT 超时、客户端休眠等问题。
核心不是“连上”,而是“连得久、断得明、重连快”。微信小程序、iOS Safari 对空闲连接尤其敏感,60 秒没数据就可能静默关闭。
conn.SetPingHandler + 定期 conn.WriteMessage(websocket.PingMessage, nil)conn.SetReadDeadline 和 conn.SetWriteDeadline 必须设,且 pongWait 要大于 ping 周期(官方建议 pingPeriod = (pongWait * 9) / 10)conn.WriteMessage 调用都要包在 defer conn.Close() 的保护范围内,避免 goroutine 泄漏微信系推送表面是 HTTP 请求,实际水很深:Access Token 2 小时过期、每日调用量有限、42001 错误要主动刷新、45009 是限流得退避重试……手写一个 http.Post 发文本消息,上线三天准出问题。
关键不是“能不能发”,而是“发失败了有没有记录、有没有告警、有没有自动补发”。企业级系统里,一次推送失败往往意味着业务流程卡死。
sync.Once + time.AfterFunc 提前 5 分钟刷新)DoWithRetry,对 40001/42001/45009 等错误码做指数退避(time.Sleep(time.Second << uint(retry)))msgid 和接收方 userid 到数据库,便于后续查证是否送达真正难的从来不是“怎么推”,而是“推没推成功”“谁没收到”“失败要不要重试”“重试几次合适”——这些逻辑不会出现在 hello world 示例里,但线上出问题时,它们才是第一现场。
上一篇:UC浏览器英文版入口及使用教程
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
正版软件
正版软件
正版软件
正版软件
正版软件
1
2
3
7
9