Golang WebSocket 疑难杂症：单标签页断线问题排查

在使用Golang的gorilla/websocket库构建WebSocket应用时，开发者经常会遇到一些挑战。本文将深入分析一个常见问题：在本地开发环境（Chrome，两个标签页分别访问localhost和IP地址）下，其中一个标签页（例如通过IP访问的标签页）无法持续接收WebSocket消息。

问题描述：

使用Go 1.16和gorilla/websocket 1.4.2版本，在Windows 10系统上进行开发。通过localhost和IP地址分别访问同一WebSocket服务，发现一个现象：刷新其中一个标签页后，该标签页能正常收发消息，但另一个标签页却无法接收或发送消息，除非也进行刷新。这提示问题并非网络连接本身，而是WebSocket连接管理。

问题代码片段（简化版）：

服务器端代码的核心在于ws函数，负责处理WebSocket连接升级和消息收发。 问题在于使用了全局变量ws来存储websocket.Conn对象：

var ws *websocket.Conn // 全局变量  func ws(c *gin.Context) {     var err error     ws, err = upgrader.Upgrade(c.Writer, c.Request, nil)     // ...后续代码... }

问题根源分析：

核心问题在于全局变量ws。所有连接都复用同一个websocket.Conn对象。当新连接建立时，ws被重新赋值，之前的连接被覆盖，导致其他标签页无法接收消息。每个连接都应拥有独立的websocket.Conn对象。

解决方案：

避免使用全局变量ws，为每个连接创建新的websocket.Conn对象。 正确的做法是在ws函数内部处理每个连接，而不是使用全局变量。 修改后的代码应将ws变量的限制在ws函数内部。 这通常需要为每个客户端连接创建一个独立的goroutine来处理连接和消息收发。

通过以上分析和修改，可以有效解决单标签页断线问题，确保所有WebSocket连接都能稳定地进行数据交互。

以上就是Go WebSocket连接：为何一个标签页无法持续接收消息？的详细内容，更多请关注php中文网其它相关文章！