clientwebsocket 连接关键在于状态判断、分片重组、心跳驱动和异常恢复：需检查 state、循环接收分片、手动发 ping、指数退避重连，否则弱网下会悄无声息掉线。
用 ClientWebSocket 连接 WebSocket 服务端
连接本身不难，但容易卡在状态判断和异常吞没上。关键不是“能不能连”，而是“连失败了有没有报出来”。ClientWebSocket 的 ConnectAsync 是异步阻塞调用，必须等它完成才能发消息；如果服务端拒绝、地址错、跨域没配好，它会直接抛 WebSocketException 或 HttpRequestException，而不是返回错误码。
- 务必检查
clientWebSocket.State，只在WebSocketState.Connecting或WebSocketState.Open时才继续，别假设调用完就一定通了 - 不要用
CancellationToken.None做默认值——超时控制必须显式传入，否则网络卡死时整个任务挂起 - 如果服务端需要认证头（如 JWT），得在
ConnectAsync前用clientWebSocket.Options.SetRequestHeader("Authorization", "xxx")设置，连上后设无效
ReceiveAsync 必须循环读、手动拼帧
WebSocket 协议允许消息分片（fragmented message），ReceiveAsync 每次只拿一帧，result.EndOfMessage == false 就说明还有后续帧。很多人写一次 ReceiveAsync 就解析，结果中文乱码、JSON 解析失败、消息截断——其实只是没等完。
- 用
List<byte></byte>缓存所有分片数据，直到result.EndOfMessage == true才转成字符串或 JSON -
buffer大小建议至少1024 * 4（4KB），太小会导致频繁分片，影响吞吐；太大又浪费内存 - 别忽略
result.MessageType：除了Text，还可能收到Binary或Close，不处理Close帧会导致连接僵死
发消息前先确认状态，发完别忘了 await
SendAsync 不是“发出去就完了”，它底层走的是 TCP 写缓冲区，如果连接已断或对方不在线，它不会立刻报错，而是在下一次发送或关闭时才暴露问题。常见现象是“以为发成功了”，实际服务端根本没收到。
- 每次发之前加判断：
if (clientWebSocket.State != WebSocketState.Open) return;，别依赖 try-catch 拦异常 -
SendAsync返回的是Task，必须await，否则可能在发送中途就执行后续逻辑，甚至提前关闭 socket - 发文本用
Encoding.UTF8.GetBytes(...)转字节数组，别直接传字符串——SendAsync只接受ArraySegment<byte></byte>
心跳和重连不能靠 Ping/Pong 自动维持
.NET 的 ClientWebSocket 确实支持 WebSocket.ReceiveAsync 自动响应 pong，但它**不自动发 ping**。很多服务端 30 秒没收到 ping 就断连，客户端却毫无察觉，表现为“突然收不到消息”，其实是连接静默断开了。
- 得自己用
Timer定期调用clientWebSocket.SendAsync(..., WebSocketMessageType.Ping, ...) - 重连逻辑要独立于接收循环：收到
Close帧或捕获到连接异常后，清空 buffer、重建ClientWebSocket实例再重试，复用旧实例大概率失败 - 重试间隔建议指数退避（如 1s → 2s → 4s），避免瞬间打爆服务端
最麻烦的从来不是连上或发消息，而是连上之后“它到底还活着吗”——状态判断、分片重组、心跳驱动、异常恢复，这四块漏掉任何一块，都会让客户端在高并发或弱网下悄无声息地掉线。
