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连接都能稳定地进行数据交互。
