websocket服务端异常捕获需分层设计：握手阶段手动校验http状态码与请求头，连接生命周期依赖事件监听，消息处理须隔离异常并降级，心跳超时需联动中间件配置。
WebSocket 服务端异常捕获不能只靠 try/catch 包裹 new WebSocket() 或 send() 调用——因为多数关键异常（如连接中断、握手失败、心跳超时）不抛出 Java/Python/Node.js 的标准 Exception，而是通过事件回调、状态码或底层 I/O 错误暴露。真正健壮的服务端异常处理，需分层设计：协议层、连接层、业务层协同响应。
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
握手阶段异常必须手动校验 HTTP 响应
WebSocket 连接始于 HTTP 升级请求，服务端若返回非 101 状态码（如 403、401、502），不会触发框架级异常，但连接实际失败。
- 在自定义 Upgrade 处理器中（如 Netty 的
ChannelInboundHandler、Spring Boot 的HandshakeInterceptor、Node.js 的ws.Server的'upgrade'事件），必须解析原始 HTTP 请求头与响应逻辑 - 检查
Sec-WebSocket-Key是否合法、Origin 是否白名单、AppKey 是否存在、签名是否过期 - 显式调用
response.setStatus(403)并写入错误体，避免静默拒绝
连接生命周期异常靠事件监听而非 try/catch
服务端无法在 onOpen 后对“连接突然断开”做同步捕获，必须注册异步事件：
- Java（Netty/Undertow）：监听
channelInactive()、exceptionCaught()，区分ClosedChannelException（正常关闭）与IOException: Connection reset（RST 强制断连） - Node.js（ws 库）：绑定
connection实例的'close'、'error'、'pong'事件；注意'error'仅覆盖部分底层 socket 错误，'close'才是最终连接终结信号 - Python（websockets 库）：使用
async for message in websocket:的except websockets.exceptions.ConnectionClosed及其子类（如ConnectionClosedError、ConnectionClosedOK）
消息处理异常需隔离+降级，避免阻塞整个连接
单条消息解析失败（如 JSON 格式错误、字段缺失、权限越界）不应导致连接关闭：
- 对每条
onMessage做独立 try/catch，记录结构化错误日志（含 client IP、message ID、错误堆栈） - 抛出业务异常时，主动发送
{ "type": "error", "code": 4001, "msg": "invalid payload" }给客户端，而非让连接断裂 - 使用线程/协程池处理耗时业务逻辑，防止
onMessage阻塞 I/O 线程，引发心跳超时连锁断连
心跳与超时异常要联动中间件配置
1006 断连占生产环境 70% 以上，根源常在 Nginx、ALB、Tomcat 等中间件空闲超时小于心跳周期：
- 服务端必须设置
pingInterval=30s，且要求所有中间层proxy_read_timeout ≥ 90s（建议 3 倍心跳间隔） - 在
pong回调中更新连接最后活跃时间戳，超时未收到 pong 则主动close(1001, "timeout") - 不依赖
setIdleTimeout()单一参数——它只控制读空闲，写超时、SSL handshake timeout、TCP keepalive 需单独配
