Go WebSocket 连接关闭码应该从哪里读取

Go WebSocket 的关闭码通常从读循环返回的错误中读取，具体类型取决于所用库。本文使用 github.com/gorilla/websocket：调用 ReadMessage 或 NextReader 出错后，通过 errors.As 提取 *websocket.CloseError，再读取 Code 和 Text。不要把本地主动发送的关闭码、底层 TCP 错误或 HTTP 握手状态混成同一种结果。

库官方文档：https://pkg.go.dev/github.com/gorilla/websocket

协议规范：https://www.rfc-editor.org/info/rfc6455/

问题：先区分发送意图与接收结果

例如服务准备以 1000 正常关闭连接，这只是本地的发送意图；客户端实际观察到什么，要看关闭控制帧是否被收到，以及传输如何结束。双方同时发起关闭时，也不应假设它们记录到的一定是同一个状态。

最小配方：从读错误提取 CloseError

在已有连接的唯一读循环中，先处理读取错误，再做类型提取。不要对普通数据帧的前两个字节自行解析关闭码；关闭控制帧由库处理，不能当作应用消息正文消费。

// 放在已有 ReadMessage 读循环的错误分支中。
var closeErr *websocket.CloseError
if errors.As(err, &closeErr) {
    // Code 是整数，Text 是可选说明；二者分别记录。
    log.Printf("websocket end code=%d text=%q",
        closeErr.Code, closeErr.Text)
} else {
    log.Printf("websocket read error: %v", err)
}
// 此处应退出读循环，不要继续重复读取同一失败连接。

以上片段需要 errors、log 与 websocket 导入，完整示例见后文。errors.As 可以处理保留了 Unwrap 链的包装错误；若上层用字符串拼接丢掉了原错误类型，提取就无法正常工作。记录错误时使用能够保留错误链的包装方式。

接收关闭帧、读循环、终止错误、状态码、说明文本和传输错误构成两组信息：读循环产生终止错误；终止错误可能带状态码及说明文本，也可能只是传输错误。图中连线表示分类关系，不表示每种错误都来自对端关闭帧。

关键处理：保持读循环并保留默认关闭行为

接收关闭、ping 与 pong 控制消息需要持续读取连接。即使业务只向客户端推送，也要安排一个读任务处理控制消息，而不是发送完就永远不读。Gorilla 的并发约定是一名读者与一名写者，不应为了“抓关闭码”再启动第二个竞争读取的 goroutine。

多数场景直接在读错误里处理关闭信息即可。只有确实需要在发送关闭回复前执行特定动作时，才考虑 SetCloseHandler。它的回调运行于读取相关调用中；替换默认处理器会替换默认回复行为。若只是增加观察，应在自定义回调中谨慎委托保存下来的默认处理器，而不是悄悄取消关闭握手。

读取失败后结束这个读循环。不要把终止错误打印后立即 continue，反复从同一失败连接取错误；更不要在该错误分支里无限制重连。

变体：浏览器事件与其他 Go 库

浏览器端常用关闭事件中的 code 和 reason，Go 服务端则使用自己所选库的接口，两边的 API 形状不同。名称相同并不代表有统一的 Go 标准库方法；net.Conn 也不会直接解析 WebSocket 关闭帧。

迁移到其他 Go WebSocket 库时，先查它的读错误类型或状态提取函数，再调整封装。不要复制 Gorilla 的 CloseError 类型断言到不相关的库，也不要只凭错误文本中包含一个数字就认定它是关闭码。

兼容坑：无状态与异常断开不是对端业务码

1005 表示没有可用的关闭状态，1006 表示异常终止这一类观察结果，它们是保留表示，不能放进关闭控制帧当作发送码。尤其看到 1006，不能写成“服务器发送了 1006”；它不能替你解释究竟是代理、进程退出、网络中断还是其他原因。

1000 通常表示正常关闭；1001 通常与端点离开有关。是否应触发业务告警，还要结合业务场景、断开频率与是否预期关闭，不能仅凭一个码决定重试。关闭说明文本也可能为空，或来自对端，应限制日志长度并避免将它当成可信命令或未转义 HTML。

Gorilla 的 Conn.Close 只关闭底层连接，不发送或等待关闭控制帧。主动优雅关闭需要先按协议发送关闭控制消息，并给等待与清理设定边界。本地关闭意图、接收关闭信息、传输错误和清理结果应分别记录。

图中的连接管理者负责读任务和资源清理，关闭记录同时关联发送意图与接收结果。这种数据组织能防止把“我希望正常关闭”误报成“对端已确认正常关闭”。

完整片段：记录关闭信息并释放连接

下面是原创客户端示例，连接到用户传入的测试服务，最多等待三十秒，并限制单条消息为一 MiB。它只用于展示读取与分类；默认 URL 是本地示例地址，不表示存在这样的在线服务。读超时被当作终止错误，不能伪装成收到远端关闭帧。

package main

import (
    "errors"
    "flag"
    "log"
    "time"

    "github.com/gorilla/websocket"
)

func main() {
    endpoint := flag.String("url", "ws://127.0.0.1:8765/ws", "测试服务地址")
    flag.Parse()

    dialer := websocket.Dialer{HandshakeTimeout: 5 * time.Second}
    c, resp, err := dialer.Dial(*endpoint, nil)
    if err != nil {
        if resp != nil {
            log.Printf("upgrade HTTP status=%d", resp.StatusCode)
        }
        log.Printf("dial failed: %v", err)
        return
    }
    defer c.Close() // 独占此连接；读循环结束后释放底层资源。
    c.SetReadLimit(1  160 {
                    text = text[:160] // 日志限长；按字节截断只用于日志展示。
                }
                log.Printf("close code=%d text=%q", ce.Code, text)
            }
        } else {
            log.Printf("terminal read error: %v", err)
        }
        return // 失败后不再读取这个连接。
    }
}

已有 Go 模块可引入 github.com/gorilla/websocket，并在项目中固定所选依赖版本。本文未执行网络连接或提供伪造输出。生产长连接还需按协议设计心跳、取消、主动关闭和退避重连，不能把演示的固定三十秒期限直接当成所有业务的配置。

为什么我注册了关闭回调却没收到？先确认仍有读循环处理控制消息，并排除连接直接中断、根本没有关闭帧的情况。

1006 能直接当成服务器故障原因吗？不能，它描述异常结束的观察结果，原因需要结合错误、代理日志和两端连接标识调查。

握手返回 403 算关闭码吗？不算，那是升级阶段的 HTTP 状态；WebSocket 会话尚未成功建立时，不应按会话关闭码统计。