Go语言处理WebSocket客户端半关闭状态-Golang-PHP中文网

readmessage返回websocket.closeabnormalclosure（1006）时并非半关闭，而是tcp连接已彻底断开，此时应立即用websocket.iscloseerror确认错误类型、停止读写、清理资源并主动关闭连接。

readmessage 返回 `websocket.closeabnormalclosure` 时怎么判断是半关闭？

它不是半关闭，而是连接已彻底断开——websocket.closeabnormalclosure（1006）表示 tcp 层 rst 或 fin 已到达，websocket 协议层无法完成握手。浏览器关页、nginx 超时、手机切后台都会触发这个状态，服务端此时收不到任何关闭帧，也就谈不上“半关闭”。

Go 的 gorilla/websocket 没有暴露“读端关闭但写端仍可用”的语义；一旦底层 net.Conn 进入 EOF 或 closed 状态，ReadMessage 就会立即返回该错误，后续调用 WriteMessage 几乎必然 panic。

不要检查 conn.RemoteAddr() 是否 panic 来“探测”半关闭——它只是告诉你连接已不可用
不要在 err != nil 后还尝试 conn.WriteMessage，哪怕只写一次
websocket.IsCloseError(err, websocket.CloseAbnormalClosure) 必须放在 ReadMessage 返回非 nil 错误后的第一行，否则可能漏判

为什么不能靠 `conn.CloseWrite()` 实现 WebSocket 半关闭？

WebSocket 不是裸 TCP，它依赖帧格式和状态机。直接调 conn.CloseWrite() 会破坏协议：客户端收不到合法的 CloseMessage 帧，只能等到超时后报 1006；服务端自己也会在下次 ReadMessage 时收到 read: connection closed，而非预期的关闭码。

真正需要的是协议级握手，不是传输层操作：

conn.CloseWrite() 是 TCP 半关闭语义，对 WebSocket 无效且危险
gorilla 的 conn.WriteMessage(websocket.CloseMessage, ...) 才是标准关闭帧入口
即使你只想单向停止读（比如暂停接收），也必须用 context.WithCancel + 检查 ctx.Err() 控制循环，而不是动底层连接

客户端只关读不关写的“伪半关闭”场景如何应对？

现实中不存在客户端主动发起的 WebSocket 半关闭。但会出现一种等效现象：客户端进程卡死、网络中间件（如某些企业防火墙）静默丢弃写数据包，而读通道尚未关闭——这时服务端还能 WriteMessage 成功几次，但 ReadMessage 已无响应。

Go语言（Golang）1.26.0

Go语言（Golang）1.26.0版本官方下载，版本号 1.26.0，适合旧项目维护、兼容性测试和指定版本开发环境搭建。

下载

这不是协议允许的状态，只能靠保活机制识别：

必须设置 conn.SetReadDeadline()，超时后 ReadMessage 返回 net.OpError，而非一直阻塞
配合心跳：conn.SetPingHandler() + 定期 conn.WriteMessage(websocket.PingMessage, nil)
若连续 2–3 次 ping 无 pong 响应，或 WriteMessage 开始返回 write: broken pipe，就该主动清理连接
别等 ReadMessage 报错才行动——那时往往已晚

主动关闭时如何避免触发 1005/1006？

1005（CloseNoStatusReceived）和 1006 都是被动接收的结果，你永远不该主动发它们。想让对端看到 1000，关键在发送顺序和时机：

先调 conn.WriteMessage(websocket.CloseMessage, websocket.FormatCloseMessage(websocket.CloseNormalClosure, "ok"))
websocket.FormatCloseMessage 第二个参数长度不能超 123 字节，否则截断或 panic
写完后加 time.Sleep(10 * time.Millisecond)，给对端时间处理并回帧
再调 conn.Close()；如果写帧失败（比如网络已断），就跳过 sleep 直接 conn.Close()
注意：1005 只会在你没收到任何关闭帧时出现，说明客户端根本没走握手流程——这不是你能修复的，只能确保自己发得规范

最易被忽略的一点：所有清理动作（删 sync.Map 中的 conn、cancel context、close notify channel）必须在发完关闭帧之后、conn.Close() 之前完成。一旦 conn.Close() 被调用，连接对象就进入不可预测状态。