signalr 在 c# 中需严格配合 hub 生命周期与连接管理：hub 必须继承 hub 且避免构造注入错误；ihubcontext 是服务端推送唯一安全途径；客户端连接必须显式启动并捕获错误；websocket 升级状态和群组清理需主动监控。
SignalR 在 C# 中不是“用一下就行”的库，它依赖服务端集线器（Hub）与客户端连接生命周期的严格配合；没搞清 Hub 和 IHubContext 的分工，90% 的实时功能会卡在“连上了但收不到消息”。
Hub 类必须继承自 Hub，且不能带构造函数参数（除非注册了依赖）
常见错误是直接给 Hub 加 public MyHub(IMyService service)，结果运行时报 InvalidOperationException: No service for type 'IMyService' has been registered。SignalR 默认不走 DI 构造注入，除非你显式配置。
- 正确做法：在
Program.cs中调用builder.Services.AddSignalR()后，再注册你的服务（如AddScoped<imyservice myservice>()</imyservice>） - Hub 内部通过属性注入或
Context.RequestServices.GetService<imyservice>()</imyservice>获取实例（后者更可控，避免构造时依赖未就绪） - 不要在 Hub 里开线程、存长生命周期对象——每次客户端调用都会新建 Hub 实例，状态不会跨调用保留
客户端连接必须显式启动，start() 失败不会抛异常，但后续调用全静默失败
JS 客户端写 const connection = new signalR.HubConnectionBuilder().withUrl("/myhub").build(); connection.start(); 看似简单，实际 start() 是 Promise，不 await / .catch 就根本不知道它卡在 CORS、404 或认证失败上。
- 务必加错误处理：
connection.start().catch(err => console.error("SignalR 连接失败:", err)) - .NET 客户端同理：
await connection.StartAsync()必须 await，否则后续InvokeAsync报InvalidOperationException: Connection was not started - 检查浏览器开发者工具 Network 标签页，确认 WebSocket 连接是否成功升级（Status 101），而非 fallback 到 Long Polling 后静默断开
IHubContext<myhub></myhub> 是服务端主动发消息的唯一安全途径
想从 Controller、BackgroundService 或其他非 Hub 上下文推送消息？别试 new MyHub().Clients.All.SendAsync(...)——这会创建孤立 Hub 实例，Clients 属性为 null。必须通过 DI 获取 IHubContext<myhub></myhub>。
- 注册后，在 Controller 构造函数中注入：
public MyController(IHubContext<chathub> hubContext)</chathub> - 发送时注意目标范围：
hubContext.Clients.All.SendAsync("ReceiveMessage", user, message)（全量）、Clients.Client(connectionId)（单个）、Clients.Group("admin")（需先调用await Groups.AddToGroupAsync(...)） - 群组名区分大小写，且不会自动清理离线用户——得监听
OnDisconnectedAsync手动移出群组，否则发消息会堆积失败任务
完整源码的关键不在“能跑”，而在 Hub 生命周期、连接状态管理和错误传播路径是否闭环。比如 OnConnectedAsync 里没记录 connectionId，后面就无法定向推送；又比如没处理 Abort 和 Close 的差异，会导致重连时重复加入群组。这些点不写进日志，调试时只能靠猜。
