Go WebSocket连接：为何一个标签页无法持续接收消息？

本文针对Go语言gorilla/websocket库中一个常见问题进行分析和解决：使用localhost和IP地址分别访问同一WebSocket服务时，其中一个标签页无法持续接收消息。问题根源在于服务器端代码使用了全局变量存储websocket.Conn对象，导致新连接覆盖旧连接。解决方案是避免使用全局变量，为每个连接创建独立的websocket.Conn对象，并在独立的goroutine中处理每个连接，从而确保所有WebSocket连接都能稳定地进行数据交互。 文章详细阐述了问题现象、代码示例、问题分析及解决方案，适合Go语言开发者排查WebSocket连接问题。

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

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于Golang的相关知识，也可关注golang学习网公众号。