close()方法用于主动终止WebSocket连接，触发受控关闭握手，可传入1000–4999状态码及≤123字节原因字符串；调用后readyState立即变为CLOSING，收响应后转CLOSED并触发onclose。
HTML5 中的 close() 方法用于主动终止 WebSocket 连接，它不是简单“断开”，而是触发一个受控的关闭握手流程，并可携带状态码与可选原因字符串。该方法调用后，连接状态立即变为 CLOSING，待对端响应后才变为 CLOSED。正确使用 close() 及理解状态码，对实现健壮的实时通信至关重要。
close() 方法的调用方式与参数含义
WebSocket 实例提供 close(code, reason) 方法，两个参数均为可选，但语义明确：
- code（状态码）：16 位无符号整数，范围为 1000–4999；1000 是标准正常关闭码，1001 表示端点离开（如页面卸载），1002/1003 分别表示协议错误或数据类型不支持；1004、1005、1006 已废弃，不应使用；4000–4999 为应用自定义范围，需双方约定含义。
-
reason（原因）：UTF-8 编码字符串，长度不超过 123 字节；用于调试或日志，不建议传递敏感信息；服务端可通过
event.reason在onclose中读取。
示例：ws.close(1001, "Page is navigating away");
关闭过程中的连接状态流转
调用 close() 后，WebSocket 的 readyState 会按顺序变化：
立即学习“前端免费学习笔记（深入）”；
- 从
OPEN (1)→ 立即变为CLOSING (2)（此时仍可接收消息，但不可再调用send()）； - 收到对端返回的关闭帧后 → 变为
CLOSED (3)，并触发onclose事件； - 若未收到响应且超时（通常由底层协议决定），也会最终进入
CLOSED状态，但event.code可能为 1006（异常关闭）。
注意：readyState === CLOSING 期间监听 onmessage 仍有效，但应避免在此阶段发起新操作。
服务端如何响应与校验关闭帧
WebSocket 协议要求关闭必须双向确认。浏览器发出关闭帧后，服务端需：
- 解析客户端发送的
code和reason，判断是否合法（例如拒绝非 1000–1013 或 4000+ 的 code）； - 返回相同 code 的关闭帧（RFC 6455 规定，服务端不得自行更改 code）；
- 在返回前完成资源清理（如注销用户心跳、释放会话内存），但须在合理时间内响应，避免连接挂起。
常见错误：服务端忽略关闭帧、静默断连、或返回非法 code（如 0 或 1005），将导致浏览器记录异常并可能影响重连逻辑。
实际开发中需规避的典型问题
很多连接异常看似随机，实则源于 close() 使用不当：
- 未传 code 直接调用
ws.close()→ 浏览器默认使用 1000，但服务端若强制校验非 1000 的业务码，会导致关闭失败； - 在
onclose回调中再次调用close()→ 无害但冗余，因状态已是 CLOSED； - 页面卸载前未主动 close（如未监听
beforeunload）→ 浏览器可能延迟关闭，服务端长时间收不到关闭帧，误判为掉线； - 自定义 code 使用 1004、1005、1006 或小于 1000 的值 → 违反规范，部分运行时（如 Safari）会直接报错或静默处理。
建议统一封装关闭逻辑，例如：function disconnect(ws, code = 1000, reason = "") { if (ws.readyState === WebSocket.OPEN) ws.close(code, reason); }
