直接用 gorilla/websocket 是因标准库仅支持 websocket 升级，缺乏连接管理、心跳、编解码等生产必需能力；gorilla 提供安全默认（如 checkorigin）、超时控制和 json 支持，并需配合 token 鉴权、内存/redis 映射、心跳保活及事件驱动推送确保高可用。
为什么直接用 gorilla/websocket 而不是标准库？
Go 标准库的 net/http 可以处理 WebSocket 升级，但不提供连接管理、心跳、消息编解码等基础能力。生产环境几乎没人裸写升级逻辑——容易漏掉 Origin 校验、Sec-WebSocket-Key 验证或缓冲区溢出防护。gorilla/websocket 是事实标准，它默认启用 CheckOrigin 防跨站，内置 SetReadDeadline/SetWriteDeadline 控制超时，并支持 WriteJSON/ReadJSON 简化序列化。
实操建议：
- 用
websocket.Upgrader时务必重写CheckOrigin方法，哪怕只允许特定域名，否则会被恶意客户端滥用来建立海量连接 - 连接建立后立刻调用
conn.SetReadLimit(512 * 1024)，防止客户端发超大帧导致内存暴涨 - 不要在
http.HandlerFunc里直接读写conn，应启动独立 goroutine 处理读/写，避免阻塞 HTTP 处理器
如何安全地把通知路由到指定用户或设备？
微服务场景下，用户可能同时在手机 App、Web 页面、桌面客户端登录，每个终端对应一个 WebSocket 连接。不能靠 session 或 cookie（WebSocket 不带这些），必须在握手阶段提取标识并绑定到连接。
常见做法是把用户 ID 或设备 token 放在 URL 查询参数或请求头中：
// 客户端连接时带上 token wss://api.example.com/ws?token=abc123
服务端解析后存入连接上下文：
upgrader := websocket.Upgrader{
CheckOrigin: func(r *http.Request) bool { return true },
}
conn, err := upgrader.Upgrade(w, r, nil)
if err != nil {
return
}
// 从 query 中取 token，查出 user_id
token := r.URL.Query().Get("token")
userID, _ := validateToken(token) // 你自己实现的鉴权函数
// 把 userID 和 conn 存进 map 或 Redis
clients[userID] = conn
注意点：
- URL 参数易被代理缓存或日志记录，敏感 token 建议改用
Authorization请求头传入 -
clients若用内存 map，多实例部署时无法共享连接状态，必须用 Redis + Pub/Sub 或消息队列做跨服务广播 - 用户登出或 token 失效时，要主动关闭对应连接并从存储中清理，否则出现“僵尸连接”
推送时遇到 “write tcp: broken pipe” 怎么办？
这是最常发生的错误，本质是客户端已断开（网络中断、页面关闭、App 进入后台），但服务端还在往已关闭的 socket 写数据。直接忽略会导致 goroutine 泄漏和连接堆积。
正确做法是每次写操作都检查错误，并做连接清理：
err := conn.WriteJSON(msg)
if err != nil {
if websocket.IsUnexpectedCloseError(err, "") {
log.Printf("client closed unexpectedly: %v", err)
} else {
log.Printf("write error: %v", err)
}
conn.Close() // 主动关闭
delete(clients, userID) // 清理映射
}
更稳妥的方式是加心跳保活：
- 服务端每 30 秒调用
conn.WriteMessage(websocket.PingMessage, nil) - 设置
conn.SetPingHandler回调，收到 ping 自动回 pong - 如果连续两次 write 失败（比如 ping 超时），直接 close 连接
微服务间怎么触发通知而不耦合？
订单服务生成新订单后，要通知用户服务推送给对应用户。硬编码调用用户服务的 WebSocket handler 会破坏服务边界。应该走事件驱动。
推荐方案：订单服务发布 order.created 事件到消息中间件（如 Kafka、NATS），用户服务订阅该 topic，收到后查出用户所有在线连接，逐个推送。
关键细节：
- 事件 payload 必须包含
user_id和必要上下文（如订单号、金额），避免用户服务再去查数据库 - 用户服务内部需维护“用户 ↔ 连接”的映射，且该映射要在连接建立/关闭时实时更新，否则推送会丢失
- 若单条消息需推送给成百上千人，别用循环
WriteJSON，改用conn.SetWriteDeadline+conn.WriteMessage批量发送，防止慢连接拖垮整个 goroutine
真正麻烦的从来不是写几行 WriteJSON，而是连接生命周期管理、多实例状态同步、断线重连语义、以及如何让推送既及时又不压垮下游——这些才是上线后半夜被叫起来的原因。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
