服务端推送消息必须通过di注入的ihubcontext，而非new hub()或静态调用clients.all.sendasync；因hub为瞬态对象，手动实例化会导致clients为null，且sendasync非静态方法，编译即报错cs0120。
服务端推送消息必须走 IHubContext，不是调 Hub 实例方法，也不是静态调用 —— 这是 90% 推送失败的根源。
为什么 new Hub() 或直接调 Clients.All.SendAsync() 会静默失败
SignalR 的 Hub 是瞬态对象，每次客户端调用都会新建实例，且不参与 DI 生命周期管理。手动 new MyHub() 会导致 this.Clients 为 null；而 Clients.All.SendAsync 根本不是静态方法，编译都过不去（常见错误信息：CS0120: An object reference is required for the non-static field）。
真正能跨上下文推送的唯一入口是 DI 容器注入的 IHubContext<myhub></myhub>。它背后由 SignalR 运行时维护连接映射表，和 Hub 实例完全解耦。
- 控制器里推送：构造函数注入
IHubContext<myhub></myhub>，再调hubContext.Clients.All.SendAsync(...) - 后台服务（
IHostedService）或定时任务中推送：同样必须通过IHubContext<myhub></myhub>，不能保存 Hub 引用或试图“缓存” - 别在
OnConnectedAsync里 await 长耗时操作（如查 DB、发 HTTP 请求），会阻塞握手，导致客户端报Failed to complete negotiation
Clients.User("uid") 和 Clients.Group("room-123") 的实际行为差异
两者都依赖客户端主动提供标识，但机制完全不同：
-
Clients.User("uid")要求客户端连接时携带有效用户标识（如 JWT 中的sub字段），服务端自动绑定到IHubContext.Users["uid"]；若没配认证或 token 解析失败，该调用等价于发给空集合 -
Clients.Group("room-123")是纯内存标记，需显式调用Groups.AddToGroupAsync(Context.ConnectionId, "room-123")加入，且断连后不会自动移出 —— 必须在OnDisconnectedAsync里补上Groups.RemoveFromGroupAsync(Context.ConnectionId, groupName)，否则组内堆积失效连接 ID，消息看似发出实则丢弃 - 组名建议带业务前缀（如
"notify_+ userId），避免和用户 ID 冲突；别用Groups.Count()—— SignalR 根本不提供该 API
前端收不到消息？先盯死这三处大小写与路径
SignalR 是字符串精确匹配，大小写、斜杠、后缀一个字符都不能错：
- 服务端注册路径：
endpoints.MapHub<myhub>("/notify-hub")</myhub>→ 前端 URL 必须是"/notify-hub"，不能是"/notify"或"/api/notify"（后者直接 404） - 服务端
SendAsync("ShowAlert", msg)→ 前端必须用connection.on("ShowAlert", (msg) => {...})，写成showalert或showAlert就收不到（Linux 服务器尤其严格） - 参数顺序必须一致：服务端传
SendAsync("UpdateStatus", id, status, ts)，前端回调就要定义三个形参(id, status, ts)，少一个或顺序颠倒，后面参数全为undefined - 若用 .NET 客户端（如 WPF），方法名需加
[HubMethodName("show-alert")]特性，避免驼峰转连字符出错
Azure 或多实例部署时，Groups 推送突然失效
默认内存模式下，Groups 数据只存在当前进程内存里。一台服务器上的用户加入 "admin" 组，另一台服务器发 Clients.Group("admin").SendAsync，消息根本路由不到前者——这是最隐蔽的“单机测试全通、上线就丢”的原因。
解决方案只有两个：
- 开发/测试阶段：强制单实例，或改用
Clients.All验证逻辑 - 生产环境（多服务器）：必须接入外部背板（backplane），如 Redis、SQL Server 或 Azure SignalR 服务；
services.AddSignalR().AddAzureSignalR()是最简路径，但注意 Azure SignalR 服务不支持自定义OnConnectedAsync逻辑，所有连接管理需前置到 negotiate 阶段
别指望靠重试或日志发现这个问题：消息发出去了，服务端没报错，客户端就是收不到——因为根本没发到它那台机器上。
