服务端主动关闭WebSocket必须走RFC 6455关闭帧流程：先发CLOSE帧、等待对端响应、再关底层连接；直接调用close()或terminate()会导致1006异常断开，生产环境严禁用terminate()主动下线，仅限恶意帧拦截或超时强制清理。
服务端主动调用 close() 会直接断连，但不触发标准关闭握手
直接调用底层连接的 Close()（如 Go 的 conn.Close()、Java 的 session.close()）会立即终止 TCP 连接，客户端收到的是 1006（CloseAbnormalClosure），属于异常断开。浏览器 WebSocket 对象的 onclose 事件中 e.code 为 1006，e.reason 为空，无法区分是网络故障还是服务端强制下线。
真正“主动关闭”必须走 RFC 6455 定义的关闭帧流程：先发 CLOSE 控制帧，再等对方回一个 CLOSE 帧，最后才关底层连接。
- Go（Gorilla）：用
conn.WriteControl(websocket.CloseMessage, data, ...)发帧，data必须是FormatCloseMessage(status, reason)生成的字节切片 - ASP.NET Core：调用
await webSocket.CloseAsync(WebSocketCloseStatus.NormalClosure, "reason")，框架自动封装并发送关闭帧 - Java（JSR-356）：调用
session.close(new CloseReason(CloseReason.CloseCodes.NORMAL_CLOSURE, "reason")) - Node.js（ws）：调用
ws.close(1000, "reason")，库内部完成帧构造与发送
ws.close(1000) 和 ws.terminate() 的区别必须分清
ws.close() 是规范兼容的主动关闭——它发 CLOSE 帧、等待对端响应、超时后才断 TCP；ws.terminate() 是暴力断连，等同于直接关 socket，客户端永远收不到 reason，且大概率触发重连逻辑误判为网络抖动。
生产环境严禁在业务逻辑中使用 terminate() 主动下线用户。只有两种合理场景可用它：
- 检测到恶意帧（如超长 payload、非法 opcode）后立即掐断，防止 DoS
- 在
close调用后等待超时（比如 5 秒）仍未收到对端CLOSE帧，此时用terminate()强制清理“半开连接”
注意：ws.close(1000) 不等于“立刻断开”，它只是发起握手；若客户端不响应（如已卡死或断网），服务端需靠超时机制兜底，否则连接资源持续占用。
如何精准指定某个 Session 关闭：别只存 ws 对象
单纯把 WebSocket 实例存进 map（如 map[string]*websocket.Conn）不够健壮——连接断开后对象可能仍被引用，或并发读写引发 panic。必须配合生命周期管理：
- 在
OnOpen/connection回调中，为每个连接生成唯一 ID（如 UUID 或 session token），并存入线程安全容器（Go 用sync.Map，Java 用ConcurrentHashMap，C# 用ConcurrentDictionary） - 在
OnClose/sessionClosed回调里，**务必同步从容器中删除该 ID 对应项**，否则内存泄漏+误关已断连接 - 主动关闭前，先查容器是否存在该 ID；不存在则说明已断开，跳过操作
示例（Go + Gorilla）：
var clients sync.Map // string -> *websocket.Conn<br>func closeSession(id string) {<br> if conn, ok := clients.Load(id); ok {<br> _ = conn.(*websocket.Conn).WriteControl(<br> websocket.CloseMessage,<br> websocket.FormatCloseMessage(websocket.CloseNormalClosure, "kicked"),<br> time.Now().Add(time.Second*5),<br> )<br> _ = conn.(*websocket.Conn).Close()<br> clients.Delete(id)<br> }<br>}
关闭帧里的 reason 文本不能超过 123 字节
RFC 6455 明确规定关闭帧 payload 最大长度为 125 字节，其中前 2 字节固定为状态码，剩下最多 123 字节给 UTF-8 编码的描述文本。超长会被截断甚至导致帧解析失败。
常见踩坑点：
- 传入中文日志（如
"用户因违规被管理员踢出"）实际占字节数远超字符数，易超限 - 拼接堆栈或错误详情进
reason，几乎必然溢出 - 某些库（如旧版 ws）不校验长度，静默截断，客户端看到的
e.reason是乱码或空字符串
安全做法：只传简短、可预期的英文标识，如 "kicked"、"timeout"、"auth_expired"；详细原因记日志，不要塞进帧里。
关闭动作本身不难，难的是让每一次 close() 都可追溯、可收敛、不残留。最常被忽略的是：关闭帧发出后，服务端必须进入等待状态，而不是立刻释放连接对象；同时，客户端是否真的响应了这个帧，需要靠心跳或应用层 ACK 来交叉验证——协议层的“已关闭”不等于业务层的“已确认下线”。
