WebSocket长连接依赖TCP但浏览器不暴露底层控制权，存在“半打开”风险：客户端readyState为1却无法通信。必须通过应用层心跳（非原生ping）探测真实状态，结合lastActive时间戳与空闲阈值双重判定，并在关闭前清理缓冲、监听器、定时器及引用，服务端需协同配置keepalive与主动断连策略。
WebSocket长连接依赖底层TCP，但浏览器不暴露TCP层控制权。所谓“TCP半打开连接”（即一端已断开、另一端仍认为连接有效）在WebSocket场景中表现为：客户端readyState === 1（OPEN），但实际无法收发数据——服务端可能已崩溃、网络中断、NAT超时或防火墙静默丢包。
这种情况无法靠ws.readyState准确识别，必须靠主动探测和策略性清理。
用心跳机制暴露真实连接状态
仅监听onclose或onerror不够，因为半打开时这些事件往往不触发。必须实现应用层心跳：
- 客户端每25–30秒向服务端发送一次轻量ping消息（如
{"type":"ping"}），并启动超时计时器（建议45秒） - 服务端收到后必须立即回一个pong响应（如
{"type":"pong"}），不能积压或延迟 - 若超时未收到pong，视为连接异常，主动调用
ws.close(4500, "ping timeout") - 注意：不要依赖
ws.ping()——原生WebSocket API**不提供该方法**，所有ping/pong必须走业务消息通道
空闲连接需结合心跳与使用频次双重判定
“空闲”不等于“失效”，但长期无业务交互+心跳失败，就该清理：
立即学习“前端免费学习笔记（深入）”；
- 每次成功收到pong时，更新连接的
lastActive = Date.now() - 另设空闲阈值（如120秒），定时检查：
Date.now() - lastActive > idleTimeout && ws.readyState === 1 - 满足条件时，先尝试发一次ping；若仍无响应，再执行安全关闭
- 避免单纯按时间一刀切——刚建立但尚未开始通信的连接，不应被误判为空闲
清理前确保无残留引用与待发消息
直接ws.close()可能丢消息或泄漏内存：
- 检查
ws.bufferedAmount，若大于0，说明有send()调用未真正发出，应等待或重试后再关 - 清除所有绑定的事件监听器：
ws.onmessage = null; ws.onerror = null; ws.onclose = null; - 清除心跳定时器：
clearInterval(pingTimer)或clearTimeout(pingTimeoutId) - 从连接池Map中
delete该实例，并解除业务模块对它的引用（如取消订阅、清空回调队列）
服务端协同能显著降低半打开概率
客户端单方面努力效果有限，需服务端配合：
- 服务端也应发送ping（例如每30秒），客户端收到后必须回pong，否则服务端主动断连
- 服务端设置合理的TCP keepalive参数（如
tcp_keepalive_time=600），早于NAT超时（通常300–600秒） - 服务端对无响应连接，在两次ping失败后主动
close，并记录日志供排查 - 客户端关闭时，尽量使用明确状态码（如
1000正常关闭、4500心跳超时），服务端据此区分原因
