WebSocket优雅关闭需先确认OPEN状态再调用close()，等待bufferedAmount为0确保消息发完，监听onclose事件清理资源，并依赖服务端及时响应关闭帧。
WebSocket 的 close() 方法本身是主动关闭连接的标准方式，但“优雅”关闭的关键不在于怎么调用它，而在于**如何确保关闭前数据已发送完毕、对端已知悉、且避免异常状态**。
确认连接处于 OPEN 状态再调用 close
直接调用 ws.close() 前必须检查 ws.readyState，否则在 CONNECTING 或 CLOSED 状态下调用无效，甚至可能静默失败：
-
WebSocket.CONNECTING（0）：连接尚未建立，此时调用close()无实际效果 -
WebSocket.OPEN（1）：唯一安全调用close()的状态 -
WebSocket.CLOSING（2）或WebSocket.CLOSED（3）：连接已在关闭中或已关闭，无需重复操作
建议写法：
if (ws.readyState === WebSocket.OPEN) {
ws.close(1000, 'Normal closure');
}
发送完关键消息后再关闭（带等待逻辑）
WebSocket 是异步通信，send() 调用后消息进入队列，并不保证立即发出。若发完消息立刻 close()，可能导致最后几条消息丢失。
解决思路不是轮询，而是利用 bufferedAmount 属性判断待发数据是否清空：
function gracefulClose(ws, reason = 'User initiated') {
if (ws.readyState !== WebSocket.OPEN) return;
<p>// 先发一条结束信号（可选）
ws.send(JSON.stringify({ type: 'bye' }));</p><p>// 等待缓冲区清空，再关闭
const checkAndClose = () => {
if (ws.bufferedAmount === 0) {
ws.close(1000, reason);
} else {
setTimeout(checkAndClose, 10);
}
};
checkAndClose();
}</p>
监听 close 和 error 事件做善后处理
调用 close() 后，连接不会瞬间断开，需通过事件确认最终状态：
-
ws.onclose：收到对端响应的关闭帧（或本地触发后完成握手），此时event.code和event.reason可读 -
ws.onerror：仅表示连接异常中断，不触发于正常 close()；不要在这里重连或清理资源 -
ws.onmessage在close()调用后仍可能收到未处理完的消息，应保持监听直到onclose触发
典型清理模式：
ws.onclose = (e) => {
console.log(`Connection closed: ${e.code} - ${e.reason}`);
// ✅ 此时可安全清除定时器、取消 pending 请求、释放 UI 绑定等
clearInterval(heartbeatTimer);
ws = null;
};
服务端配合：及时响应关闭帧
前端调用 close() 会发送一个关闭帧（Close Frame），但连接真正断开需双方完成握手——即服务端也需调用对应关闭方法（如 Node.js 的 ws.close() 或 socket.close()）并返回确认帧。
若服务端忽略关闭帧或延迟响应，前端 onclose 会延迟触发（甚至超时后以 1006 强制关闭）。因此“优雅”的闭环依赖服务端及时配合，建议服务端监听 close 事件后立即回应。
