C#实时聊天服务端必须用WebSocket（推荐SignalR），因其天然支持双向通信、长连接和浏览器兼容；手写TCP协议需处理粘包、心跳、重试等复杂问题，易出错。
用 WebSocket 实现 C# 服务端聊天，别碰 TcpClient 手搓协议
直接上结论：C# 做实时聊天，服务端必须用 WebSocket（.NET 6+ 推荐 Microsoft.AspNetCore.SignalR），自己用 TcpClient 或 UdpClient 拼协议是给自己埋雷。
原因很简单：WebSocket 天然支持双向、长连接、消息帧校验和浏览器兼容；而手写 TCP 协议要处理粘包/半包、心跳保活、连接异常重试、多客户端广播路由——这些 SignalR 已经帮你压进 Hub 和 IHubContext 里了。
- 常见错误现象：
SocketException: An existing connection was forcibly closed by the remote host—— 这基本是没做心跳或超时清理，客户端断连后服务端还往死连接发消息 - 使用场景：内部系统通知、客服对话、小规模实时协作，不建议硬扛万级并发（得换
SignalR+ Redis 背板） - 参数差异：
WebSocketManager（第三方库）轻量但需手动管理连接池；SignalR开箱即用，但默认用LongPolling回退，务必在客户端显式指定WebSocketsTransport
SignalR Hub 中如何安全广播消息，避免跨用户泄露
很多人把用户 ID 当作连接 ID 直接塞进 Groups.AddToGroupAsync，结果 A 用户发的消息被推给了 B 用户的多个标签页——因为没区分「逻辑用户」和「物理连接」。
正确做法是：登录成功后，用唯一业务 ID（比如 UserId）调用 await Groups.AddToGroupAsync(Context.ConnectionId, userId)；发消息时用 await Clients.Group(userId).SendAsync(...)，而不是 Clients.All 或 Clients.User(...)（后者按用户名匹配，不保证在线状态）。
- 容易踩的坑：
Clients.User("alice")会向所有叫 alice 的连接发消息，哪怕她已登出；而Clients.Group("alice")只推给当前在该组里的连接 - 性能影响：频繁调用
AddToGroupAsync/RemoveFromGroupAsync不影响吞吐，但 Group 名含特殊字符（如@、/）会导致SignalR内部解析失败，报错Invalid group name - 示例：用户退出时，应在
OnDisconnectedAsync里显式调用Groups.RemoveFromGroupAsync(Context.ConnectionId, userId)，不能只靠超时自动清理
客户端 JS 怎么接 SignalR 消息，避免重复绑定事件
前端反复调用 connection.on("ReceiveMessage", handler) 却没清理旧 handler，结果一次发消息，触发 5 次回调——这是最常被忽略的内存泄漏点。
根本原因是：SignalR 连接重建（比如网络抖动）后，新连接会保留旧的 event listener，而 JS 不会自动解绑。
- 实操建议：把 handler 定义为具名函数（如
function onReceive(msg) { ... }），连接前先connection.off("ReceiveMessage", onReceive)，再on - 使用场景：SPA 页面跳转未销毁 connection 实例时，尤其危险；Vue/React 组件卸载时必须调用
connection.stop()，否则后台持续重连 - 错误现象：
Failed to execute 'send' on 'WebSocket': Still in CONNECTING state—— 很可能是因为前一个 connection 还在 CONNECTING，你又 new 了一个
SignalR 部署到 IIS 或 Nginx 后消息不达，八成是代理配置漏了
本地跑得好好的，一上生产就收不到消息，90% 是反向代理没透传 WebSocket 协议头。
IIS 需启用 WebSocket 模块（Windows Server 2012+ 默认关），Nginx 则必须加三行配置，缺一不可：
proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade";
否则 SignalR 会降级到 ServerSentEvents 或 LongPolling，看起来能连，但延迟高、易断、不支持二进制消息。
- 兼容性影响：没配好时，Chrome 控制台 Network 标签能看到请求 status 是 200，但 WS 连接始终显示 pending；Edge 更激进，直接 fallback 到轮询
- 验证方法：打开浏览器开发者工具 → Network → 筛选
ws，看是否出现101 Switching Protocols响应 - 路径注意：
MapHub<chathub>("/chat")</chathub>对应的代理路径必须和 Nginxlocation /chat完全一致，尾部斜杠不能多也不能少
事情说清了就结束。真正麻烦的从来不是怎么发消息，而是谁该收到、什么时候该收不到、断了之后怎么续——这些边界逻辑，比写个 SendAsync 花十倍时间。
