调用 ws.close() 可关闭连接，但参数必须符合 RFC 6455：code 为 1000/1001/1002/1003 或 4000–4999 的 16 位无符号整数，reason 为 ≤123 字节 UTF-8 字符串；非法参数导致报错或 CLOSING 卡死；微信小程序需确保 readyState === 'open' 再调用 wx.closeSocket；close() 后状态变为 CLOSING，仍可收消息但不可发，最终转 CLOSED 并触发 onclose；关闭帧不保证送达，关键业务状态应通过 HTTP 同步后再 close。
直接调用 ws.close() 就能关闭连接，但传错参数会立即报错、连接卡在 CLOSING 状态，甚至触发异常关闭（code: 1006）。
close() 方法的参数必须严格符合 RFC 6455 规范
浏览器或小程序环境对 close() 的参数校验非常严格。第一个参数 code 不是“随便填个数字”，第二个参数 reason 也不是“随便传个字符串”。
-
code必须是 16 位无符号整数，且仅允许以下范围：
–1000（正常关闭）、1001（端点离开，如页面卸载）
–1002（协议错误）、1003（不支持的数据类型）
–4000–4999（应用自定义，双方需约定含义）
❌0、999、5000、NaN、"1000"（字符串）都会导致failed to execute 'close' on 'WebSocket': the code must be... -
reason必须是 UTF-8 编码的字符串，长度 ≤ 123 字节（不是字符数），不能含控制字符或敏感信息；服务端可通过event.reason读取，但客户端无法保证它被送达 - 两个参数都可省略：不传时默认为
ws.close(1000, "")，但显式传参更利于调试和日志归因
微信小程序中 wx.closeSocket 的特殊时序要求
小程序的 wx.closeSocket 是异步 API，且严重依赖连接状态。它不像原生 ws.close() 那样“调了就发帧”，而是走完整的小程序底层桥接流程。
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 必须确保
wx.onSocketOpen已触发，即readyState === 'open'；若在wx.connectSocket发起后、尚未回调onSocketOpen时就调wx.closeSocket，调用会静默失败（fail回调触发，但连接未真正关闭） -
codenumber参数虽标为“可选”，但若传入非法值（如负数、超长字符串、非数字），fail回调中会返回明确错误信息，例如invalid close code - 建议始终配对使用
success和fail回调，并在success中清理定时器、取消监听等资源，避免内存泄漏
调用 close() 后 readyState 变化与消息收发边界
很多人误以为 ws.close() 是“立刻断开”，其实它启动的是一个两段式握手过程，readyState 的变化和事件触发有明确时序。
- 调用瞬间：状态从
OPEN (1)→CLOSING (2)；此时仍可接收新消息（onmessage有效），但不能再调send()，否则抛InvalidStateError - 收到对端响应关闭帧后：状态变为
CLOSED (3)，并触发onclose事件，event.code和event.reason可读取对端返回值 - 若对端未响应（如服务端宕机、网络中断），客户端最终也会进入
CLOSED，但event.code很可能为1006（abnormal closure），event.reason为空 - ⚠️ 关键陷阱：在
CLOSING状态下监听onmessage仍有效，但不应在此阶段发起重连或新请求——状态已不可逆，只是“等待确认”
最常被忽略的一点：关闭帧本身不保证送达。服务端是否真正收到 close(1001, "Page is navigating away")，取决于网络状况和对方实现。所以业务逻辑上，不要依赖服务端“一定收到了 reason”，而应把关键状态变更（如用户登出）通过独立 HTTP 请求同步，再调用 close() 做连接层收尾。
