Go语言使用Gorilla WebSocket接收数据高并发消息传输教程【技术】-js教程-PHP中文网

readmessage死循环不加超时和错误分类会导致连接假死；应设setreaddeadline、区分closemessage与真实错误、结构化消息封装以确保连接干净退出。

go语言使用gorilla websocket接收数据高并发消息传输教程【技术】

直接用 conn.ReadMessage() 在 goroutine 里死循环读，不加超时和错误分类处理，几百个连接很快会卡在 [IO wait] 状态，不是代码写错了，是连接没被正确回收或心跳缺失导致的假死。

gorilla/websocket.Dial() 连接失败的三大常见原因

多数握手失败不是网络问题，而是服务端校验头不匹配：

Origin 头缺失或值不对（尤其对接 SockJS、Spring WebFlux 时，必须显式传 http.Header{"Origin": []string{"http://localhost"}}）
服务端启用了 TLS，但客户端没配 dialer.TLSClientConfig = &tls.Config{InsecureSkipVerify: true}（仅限开发环境）
HandshakeTimeout 太短（默认 45 秒，但某些内网设备响应慢），建议设为 10 * time.Second

ReadMessage() 卡住不返回？检查这三件事

conn.ReadMessage() 是阻塞调用，卡住 ≠ bug，但长期卡住（>2 分钟）大概率是连接异常未被感知：

Go语言（Golang）1.26.0

Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。

下载

远程服务没发 Close 帧，TCP 连接处于半开状态 —— 必须启用 SetReadDeadline()，例如每次读前设 conn.SetReadDeadline(time.Now().Add(30 * time.Second))
没处理 websocket.CloseMessage 类型消息，导致连接不主动关闭 —— ReadMessage() 返回后要判断 messageType == websocket.CloseMessage，然后调用 conn.WriteMessage(websocket.CloseMessage, nil)
没区分 io.EOF 和真实错误：用 websocket.IsUnexpectedCloseError(err, websocket.CloseGoingAway, websocket.CloseAbnormalClosure) 判断是否该重连

聚合数百连接时，消息必须带来源标识

所有连接共用一个 chan Message 时，若消息体里不含 URL 或 ID，后续解析、告警、路由全会乱套：

定义结构体时强制嵌入元信息：type Message struct { URL string; Data []byte; Timestamp time.Time }
每个连接 goroutine 内不要直接往共享 channel 发裸 []byte，先包装再 send
避免用 string(msg) 直接转 —— WebSocket 消息可能是二进制帧，应先用 websocket.MessageText / websocket.MessageBinary 判断类型，再决定解码方式

真正难的不是启动几百个 goroutine，而是让每个连接在断连、超时、协议异常时都能干净退出、可重试、不泄漏 fd —— 这些细节藏在 SetReadDeadline、IsUnexpectedCloseError 和结构化 message 封装里，漏掉任意一个，压测时都会突然崩掉几十个连接。