结论：优先选 signalr 而非原生 websocket 做业务实时通讯；仅在需控制帧格式、对接硬件或调试底层时手撸 websocket。signalr 提供自适应传输、自动降级、内置生命周期管理与广播能力，而原生 websocket 需手动处理连接、心跳、序列化及异常恢复。
直接说结论：别用原生 WebSocket 做业务实时通讯，优先选 SignalR；但如果你真要手撸 WebSocket（比如对接硬件设备、协议受限、或调试底层行为），.NET Core 确实支持，只是得自己扛连接管理、心跳、序列化、异常恢复这些事。
为什么 SignalR 是默认推荐方案
SignalR 不是 WebSocket 封装层，而是一套自适应实时通信抽象——它会按客户端能力自动降级：优先用 WebSocket，不支持就切 Server-Sent Events，再不行用长轮询。你写一次 Hub 方法，不用管传输细节。
-
Hub类里定义的public async Task方法，前端 JS 调用时自动路由、反序列化、上下文绑定（CancellationToken、HttpContext、用户标识都可用） - 内置连接生命周期事件：
OnConnectedAsync/OnDisconnectedAsync，可直接存Context.ConnectionId到IDistributedCache或内存字典 - 广播简单：
await Clients.All.SendAsync("ReceiveMessage", user, message)；定向发：await Clients.Client(connectionId).SendAsync(...) - 注意：默认内存背板只适用于单实例部署；多实例必须配
Redis或SQL Server背板，否则客户端收不到跨服务器发的消息
硬上原生 WebSocket 的典型场景和坑
只有当你需要完全控制帧格式（比如对接 Modbus over WS、自定义二进制协议）、或必须绕过 SignalR 的 JSON 序列化开销时，才考虑直接用 Microsoft.AspNetCore.Http.WebSockets。
- 必须手动启用 WebSocket 支持：
app.UseWebSockets()要放在UseRouting()之后、UseEndpoints()之前 - 不能在普通 MVC Controller 里直接操作
WebSocket—— 必须用Map扩展方法注册终结点，例如：app.Map("/ws", HandleWebSocket) - 收到的
WebSocket实例是短生命周期对象，AcceptAsync后必须立即ReceiveAsync/SendAsync，且需自行处理CloseStatus和CloseStatusDescription - 没有内置心跳：浏览器 30 秒无数据会静默断连，得自己发
Ping帧（WebSocketMessageType.Ping）并监听Pong，否则连接状态不可靠
SignalR Hub 中如何安全传参和防滥用
SignalR 默认允许任意客户端调用 Hub 方法，参数直接从 JSON 反序列化，这里最容易出问题的是类型转换和权限绕过。
- 所有入参必须显式声明类型（别用
object或dynamic），否则反序列化失败会静默丢弃调用，日志里只报Failed to bind parameter - 敏感操作必须校验
Context.User：比如删除消息前检查Context.User.FindFirst(ClaimTypes.NameIdentifier)?.Value == targetUserId - 避免在 Hub 方法里做耗时同步操作（如
File.ReadAllText），一律用await+ 异步 API；否则会阻塞整个 Hub 实例的并发处理能力 - 客户端传来的 ID 类型（如
Guid、long）务必用TryParse校验，防止FormatException导致连接中断
WebSocket 连接数突增时的真实瓶颈在哪
很多人以为瓶颈在带宽或 CPU，实际压测中常卡在 ThreadPool 线程饥饿或 Socket 文件描述符耗尽。
- .NET Core 默认线程池最小线程数是
Environment.ProcessorCount，高并发 WebSocket 长连接下，每个连接的ReceiveAsync回调可能抢占线程池线程 —— 建议调大：ThreadPool.SetMinThreads(100, 100) - Linux 上单进程默认最多 1024 个文件描述符，WebSocket 每个连接占一个；用
ulimit -n 65536提升，并在代码里捕获IOExceptionwith message"Too many open files" -
SignalR的HubLifetimeManager默认用ConcurrentDictionary存连接，百万级连接时内存和 GC 压力明显；此时应改用外部背板 + 分片策略，而不是死磕单机吞吐
真正难的从来不是“怎么连上”，而是“连上后怎么稳住、怎么扩、怎么查断连原因”。抓包看 WebSocket 帧、查 SignalR 的 trace 日志级别、监控 System.Net.Http.SocketsHttpHandler 指标，比反复改握手逻辑有用得多。
