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.php.cn/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 流程），问题就会从“连不上”迅速演变成“连上了但收不到”“收到重复消息”“集群下消息丢失”。
