<p>SignalR 是 C# 聊天室最稳选择，自动处理连接管理、降级兼容、消息分发；避免 async void、空参解构、静态状态存储，正确配置路由与代理，生产环境必用 Redis 背板。</p>
SignalR 是当前 C# 聊天室最稳的选择
不用纠结 Socket 自建通信层——SignalR 已经把连接管理、重连、消息广播、分组、身份上下文这些硬骨头啃完了。它底层自动在 WebSocket / Server-Sent Events / Long Polling 之间降级，你写一套代码就能跑在老旧 IE 和最新 Edge 上。
常见错误现象：Microsoft.AspNetCore.SignalR.HubException: Connection disconnected before invocation result was received，多数是因为 Hub 方法里用了 async void 或没 await 异步操作；或者前端调用时传了 null 参数，而服务端没校验直接解构。
- Hub 类必须继承
Hub，不能是Hub<T>（泛型 Hub 仅用于强类型客户端，实际项目中反而增加耦合） - 所有公开方法默认可被客户端调用，敏感操作（如踢人、删消息）务必加
[Authorize]或手动检查Context.User.Identity.IsAuthenticated - 发消息别用
Clients.All.SendAsync(...)直播全量，按场景选：Clients.Group("room1").SendAsync(...)（房间隔离）、Clients.Client(connectionId).SendAsync(...)（私聊） - 不要在 Hub 方法里长期持有大对象或启动后台线程——Hub 实例是瞬态的，方法执行完就可能被回收
Socket 编程只在极少数场景值得碰
除非你明确需要毫秒级可控的帧结构（比如实时协作白板的笔迹同步）、或要对接非 .NET 客户端且对方只认原始 TCP/UDP 协议，否则别碰 TcpListener + NetworkStream 这套。它不处理断线重连、心跳、粘包拆包、多路复用，你得自己补全，上线后大概率会遇到连接数上不去、内存泄漏、消息错乱。
典型翻车点：StreamReader.ReadLine() 阻塞等待换行符，但客户端没发 \n 就卡死；或用 stream.Read() 读固定长度，结果网络抖动导致一次只收到半条消息。
- 必须实现自定义协议头（含长度字段），用
BinaryReader.ReadInt32()先读长度，再读指定字节数，才能可靠拆包 - 每个连接对应一个长生命周期的
Task，需用CancellationToken配合超时和主动关闭，否则连接堆积会耗尽线程池 - 广播消息时不能简单 foreach 所有 socket 写入——并发写同一个
NetworkStream会抛IOException，得为每个连接配独立 writer 或加锁 - .NET 6+ 推荐用
System.IO.Pipelines替代裸 Stream，它内置缓冲管理和零拷贝解析，但学习成本明显高于 SignalR
聊天室状态存哪？别碰静态变量
多人聊天的核心状态——在线用户列表、房间成员映射、未读消息计数——绝不能存在 static Dictionary<string, List<string>> 里。IIS 应用池回收、K8s Pod 重启、SignalR Scale-out 多实例部署，都会让这个字典瞬间失联或不同步。
真实报错场景：NullReferenceException 在 OnDisconnectedAsync 里访问静态集合，因为另一个实例刚清空了它；或用户看到“已加入房间”，但别人收不到他的消息——其实是两个 SignalR 实例没共享组信息。
- 单机小项目：用
IDistributedCache（哪怕只是MemoryDistributedCache）存房间-连接ID 映射，确保OnConnectedAsync/OnDisconnectedAsync操作原子 - 生产环境必须上 Redis：注册
RedisSignalRBackplane，它自动同步所有 SignalR 实例的组关系和广播指令 - 用户在线状态别只靠
OnConnected/OnDisconnected——网络闪断时客户端可能没触发断开，得配合心跳检测（SignalR 内置 ping/pong，但需在客户端设withAutomaticReconnect并监听onreconnecting） - 消息历史如果要持久化，直接写入数据库（如 PostgreSQL 的
jsonb存消息体），别试图缓存在内存里做“高性能”
前端连不上？先看这三件事
90% 的 “SignalR 连接失败” 问题跟后端逻辑无关，而是跨域、路径或版本错配。浏览器控制台里出现 Failed to load resource: the server responded with a status of 404 () 或 WebSocket connection to '...' failed，基本锁定在这几个点。
- 确认 Startup.cs / Program.cs 里调用了
app.UseEndpoints(endpoints => { endpoints.MapHub<ChatHub>("/chat"); })，且路径和前端new HubConnectionBuilder().withUrl("/chat")完全一致（注意末尾不加斜杠） - 如果用了 Nginx/Apache 反向代理，必须显式开启 WebSocket 支持：
proxy_set_header Upgrade $http_upgrade;和proxy_set_header Connection "upgrade"; - 前后端 SignalR 版本要对齐：.NET 6 后端必须配 @microsoft/signalr@6.x 前端包，用 7.x 会因 JSON 序列化差异导致
Invocation binding failed - Chrome 浏览器地址栏输
https://yoursite.com/chat/negotiate，能返回 JSON 就说明 Hub 路由通了；返回 404 则是路由注册漏了或中间件顺序错了（UseRouting必须在UseEndpoints前）
SignalR 的坑不在“怎么写”，而在“怎么不让它悄悄失效”——连接生命周期、状态存储边界、前后端协议对齐，这三处稍一松懈，上线后的问题就是偶发、难复现、日志里找不到线索。
