gorilla/websocket 是 golang 微服务实时推送的合理起点，但需解决跨 pod 广播、origin 校验、连接关闭写 panic、writepump 设计及 redis 协调等核心问题。
gorilla/websocket 是 Golang 微服务中实现实时推送的合理起点，但它本身不解决跨服务通信问题。单机场景下它足够稳；一旦服务拆分或部署到 Kubernetes，直接靠 map[<em>websocket.Conn]bool</em> 广播就会失效——连接分散在不同 Pod，websocket.Conn 无法跨进程传递。
CheckOrigin 配置错误导致连接卡在 handshake 阶段
浏览器发 new WebSocket("ws://...") 后没反应，控制台也无报错？大概率是 Upgrader.CheckOrigin 拦住了。
- 默认行为是拒绝所有非同源请求，连
http://localhost:3000→ws://localhost:8080都会被拒 - 开发阶段可临时设为
func(r *http.Request) bool { return true }，但上线前必须替换 - 生产环境推荐用
strings.HasSuffix(r.Header.Get("Origin"), ".yourdomain.com")，兼容子域名（如dev.yourdomain.com、app.yourdomain.com） - 若前端走 Nginx，确认配置了
proxy_set_header Origin $http_origin;，否则Origin头为空，校验永远失败 -
Referer不可靠，别用它做来源判断
WriteMessage panic: "write tcp: use of closed network connection"
这不是网络问题，是往已关闭的 *websocket.Conn 写数据。常见于客户端刷新页面、断网后服务端还拿着旧连接发消息。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 不要在广播循环里直接调
conn.WriteMessage()，尤其不能复用同一个conn被多个 goroutine 并发写 - 每个连接应配专属
writePumpgoroutine，监听自己的send chan []byte，串行执行写操作 - 读协程必须监听
io.EOF或websocket.CloseMessage，一捕获就调conn.Close()并关闭对应sendchannel - 写之前加
conn.SetWriteDeadline(time.Now().Add(5 * time.Second))，防止单个卡顿拖垮全部推送 - 缓冲 channel 大小建议设为
16–64，太大积压内存，太小容易丢通知
单机广播能跑，上 K8s 就收不到消息
微服务部署后，WebSocket 连接天然分散在多个实例上，本地 broadcast chan []byte 只能触达本 Pod 的连接。
- 跨实例推送必须引入外部协调中间件，Redis 是最轻量且通用的选择
- 连接建立时，向 Redis 写入
user:<id></id>→{pod_addr, conn_id}，带 TTL（比如30s） - 推送前先查 Redis 获取目标用户当前所在 Pod 地址，再通过内部 HTTP/gRPC 调用该 Pod 的本地推送接口
- 避免用全局锁或分布式锁同步状态——延迟高、易争抢；Redis 的原子操作 + TTL 自清理更可靠
- 如果业务允许弱一致性（如通知类），也可退化为“每个 Pod 向自己连接广播”，配合前端重连兜底
真正难的不是写通第一个 conn.WriteMessage()，而是让成百上千个连接在滚动发布、网络抖动、Pod 重建时仍保持状态可追溯、消息不堆积、资源不泄漏。这些细节藏在心跳检测频率、channel 缓冲大小、Redis key 过期策略和 write deadline 设置里，而不是架构图上那个醒目的「WebSocket」框里。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
