17370845950

SignalR 是自动适配传输协议的实时通信抽象层，核心是 Hub 类，通过 IHubContext 实现服务端广播，需严格匹配路由与跨域配置，禁用手动实例化或静态调用。

SignalR 不是一个“你要手动选传输协议”的底层通信库，它是一套自动适配、开箱即用的实时通信抽象层——你写一次 Hub 方法，它自己决定用 WebSocket、SSE 还是长轮询，只要客户端和服务器能力允许。

Hub 是核心，不是可选项

你几乎不会直接操作 PersistentConnection（旧版遗留），现代 SignalR（ASP.NET Core SignalR）只推荐用 Hub。它本质是一个带连接生命周期管理的 C# 类，方法能被前端 JS 或 .NET 客户端直接调用，反过来也能从服务端调用客户端 JS 函数（比如 clients.All.sendNotification(...)）。

• Hub 自动注入 IHubContext，用于服务端非 Hub 内部（如 Controller、BackgroundService）发消息
• 所有客户端方法调用都走 JSON 序列化，默认用 System.Text.Json；若需更小体积，可切换 MessagePack（但要求客户端也支持且 XHR Level 2）
• 不要试图在 Hub 构造函数里做耗时初始化——它每次请求都新建实例；改用 OnConnectedAsync() 或依赖注入单例服务

服务端注册和路由必须匹配客户端连接地址

很多连不上、404 或 405 错误，根源就在这一步没对齐：

• 在 Program.cs 中加服务：

  builder.Services.AddSignalR();

• 启用终结点时指定路径：

  app.MapHub("/chatHub");

• 前端 JS 必须用完全一致的路径连接：new HubConnectionBuilder().withUrl("/chatHub")
• 如果部署在子路径（如 https://www./link/9bf7386a84415b80b67c90f0c1c743c7），URL 要补全："/app/chatHub"，否则跨域或路由 404

客户端连接失败？先看浏览器控制台和 Network 面板

SignalR 会按优先级自动降级，但你得知道它到底卡在哪一层：

• 打开浏览器 DevTools → Network 标签页，筛选 XHR 和 WS
• 若看到 negotiate 返回 404：检查 MapHub 路由是否注册、是否在 UseRouting() 之后
• 若看到 WebSocket 连接失败（Failed to construct 'WebSocket'）：确认 IIS/Nginx 是否启用了 WebSocket 代理（如 Nginx 需加 proxy_http_version 1.1 + Upgrade 头）
• 若一直 fallback 到 longPolling：可能是跨域未配 CORS，或 IE11 等老浏览器不支持 WebSocket —— 此时不要硬改传输方式，先修环境

别把 Hub 当普通类来 new 或静态调用

常见错误写法：

• ChatHub.BroadcastMessage("hi") → ❌ Hub 实例由框架创建，无状态，不能静态调用
• new ChatHub() → ❌ 构造函数里拿不到 Clients 或 Context
• 在 Hub 里存客户端连接 ID 到静态 List → ⚠️ 集群部署下失效，且不线程安全

正确做法：

• 用 IHubContext 从 DI 获取上下文，在 Controller 或后台服务中广播
• 用 Groups 管理房间，而不是靠自己维护连接列表
• 需要持久状态？交给 Redis 或数据库，别塞进 Hub 实例字段里

SignalR 的“简单”是建立在理解它自动管理连接生命周期的基础上的；一旦绕过这套机制（比如手动 new Hub、自己拼接 URL、忽略 negotiate 流程），问题就会从“连不上”迅速演变成“连上了但收不到”“收到重复消息”“集群下消息丢失”。