WebSocket服务端如何主动关闭连接教程 WS连接生命周期管理方法-js教程-PHP中文网

服务端必须发送标准Close帧才能真正断开WebSocket连接，仅调用close()不等于连接终结；需先确认连接处于OPEN状态，再发送含规范状态码的Close帧，等待对端响应或超时后清理资源。

服务端主动调用 `close()` 才算真正断开

websocket 服务端不能靠“不发消息”或“关闭 socket 文件描述符”来结束连接——必须发送标准 close 帧。否则客户端会卡在 closing 状态，服务端资源不释放，甚至触发重连风暴。

不同框架的关闭方式本质一致：先构造并发送关闭帧（含状态码），再等待对端响应（可设超时），最后清理本地连接对象。

FastAPI 中用 websocket.close(code=1000, reason="正常关闭")，它会自动处理帧交换和状态迁移
gorilla/websocket（Go）需显式调用 conn.WriteMessage(websocket.CloseMessage, websocket.FormatCloseMessage(websocket.CloseNormalClosure, "ok"))，再调 conn.Close()
ws（Node.js）直接 ws.close(1000, "bye") 即可，库已封装握手逻辑
Python websockets 库推荐用 await websocket.close(code=1000, reason="done")，内部会等对方 ACK 或超时后强制终止

`close()` 调用后必须等响应或超时，不能立刻销毁上下文

调用 close() 只是发起关闭握手，不是连接终结的终点。服务端仍需监听对方返回的 Close 帧，或等待超时才可安全释放内存、取消定时器、解绑事件。

常见错误是：一调 close() 就立刻从连接池中移除 websocket 对象，结果对方还没收到关闭帧，后续消息仍被路由过去，引发 ConnectionClosedOK 异常或数据丢失。

FastAPI 中应在 except WebSocketDisconnect: 块里做清理，而不是在 close() 后立刻执行
Python websockets 库中，close() 返回一个 asyncio.Task，建议 await 它完成，或至少用 asyncio.wait_for(close_task, timeout=5)
Go 的 gorilla/websocket 默认不阻塞，需手动调 conn.ReadMessage() 检查是否收到对方的 Close 帧，或依赖 SetReadDeadline 控制等待窗口

关闭前必须检查 `readyState` 或底层连接是否还活跃

服务端主动关连接前，得确认它还在 OPEN 状态。若连接已因网络中断进入 CLOSED，再调 close() 会抛异常（如 FastAPI 的 RuntimeError: Already closed），或静默失败。

WebSocket 8.18.2

WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。

下载

尤其在心跳检测、闲置踢出等场景下，不能仅凭定时器触发就无条件关——要先验证连接是否真实可用。

FastAPI：if websocket.client_state == WebSocketState.CONNECTED: 再关（注意不是 websocket.application_state）
Python websockets：if websocket.open: 是最简判断，但更稳妥的是捕获 ConnectionClosed 异常后再跳过关闭逻辑
Go：if conn.State() == websocket.Connected，否则跳过
Node.js：if (ws.readyState === WebSocket.OPEN)