根本原因是hub类名称不匹配或客户端未启用调试日志；需确保createhubproxy参数与服务端hub类名一致，并启用tracelevel.all和tracewriter输出排查。
signalr hub方法调用失败：.net客户端收不到js发来的消息
根本原因通常是hub类方法签名不匹配或未启用cors。.net客户端（hubconnection）和js客户端都必须连接到同一个hub路径，且方法名、参数类型、顺序要完全一致。
- 检查Hub类方法是否为
public且非static；JS调用invoke时传参类型需与C#端Task<t></t>返回值或void签名兼容 - .NET客户端连接前必须调用
WithUrl指定正确地址，例如new HubConnectionBuilder().WithUrl("https://api.example.com/chatHub")，不能漏掉/chatHub后缀 - 若服务端是ASP.NET Core 6+，
Program.cs中必须显式启用CORS并允许凭据：builder.Services.AddCors(o => o.AddPolicy("AllowAll", p => p.AllowAnyOrigin().AllowAnyMethod().AllowCredentials()));，并在app.UseCors("AllowAll")位置正确插入 - JS端调用
connection.invoke("SendMessage", "user1", "hi")时，C# Hub里对应方法必须是public async Task SendMessage(string user, string message)——参数名可不同，但类型和顺序不能错
JS客户端无法连接到.NET Core SignalR服务：404或500错误
最常见的是路由注册顺序错误或Hub路径配置不一致。SignalR Hub不是普通控制器，它依赖MapHub<t></t>中间件，且必须在app.MapControllers()之后、app.UseEndpoints()内注册。
- 确认
Program.cs中已调用app.MapHub<chathub>("/chatHub")</chathub>，路径/chatHub必须与JS端new HubConnectionBuilder().withUrl("/chatHub")完全一致（注意开头斜杠） - 如果用了HTTPS反向代理（如Nginx），需确保
X-Forwarded-Proto头被正确传递，并在builder.Services.AddSignalR()后加.AddJsonProtocol(o => o.PayloadSerializerOptions.PropertyNamingPolicy = null)避免大小写序列化问题 - JS端报
Failed to start the connection: Error: Unable to connect to the server，先用浏览器直接访问https://yoursite.com/chatHub/negotiate看是否返回JSON；返回404说明Hub没注册，返回500则可能是Hub构造函数抛异常（比如DI注入失败）
.NET客户端接收消息延迟或丢失：UseWebSockets()没生效
默认情况下，HubConnection会按WebSockets → ServerSentEvents → LongPolling降级。但.NET客户端（尤其是Windows桌面应用）若没显式启用WebSocket传输，可能卡在LongPolling模式，导致延迟高、消息乱序。
- 创建连接时必须显式指定传输方式：
new HubConnectionBuilder().WithUrl(url, HttpTransportType.WebSockets).Build()；不传HttpTransportType参数就走自动协商，而.NET Framework客户端默认不支持SSE - 确保服务端启用了WebSocket：在
Program.cs中builder.Services.AddSignalR()之前加builder.WebHost.ConfigureKestrel(serverOptions => { serverOptions.ConfigureHttpsDefaults(opt => opt.Http2SupportEnabled = true); });，并确认IIS/KESTREL支持WebSocket（Linux需检查libuv版本） - JS端监听
on事件时，方法名必须与C#端Clients.All.SendAsync("ReceiveMessage", ...)中的字符串完全一致（区分大小写），否则消息静默丢弃
跨平台身份验证失效：JWT Token在.NET客户端中不自动携带
JS客户端通过accessTokenFactory能自动在每个请求头加Authorization: Bearer xxx，但.NET客户端不会自动读取localStorage或发送Token——必须手动注入。
- .NET客户端需在
WithUrl后链式调用ConfigureHttpOptions：.ConfigureHttpOptions(o => o.Headers.Add("Authorization", $"Bearer {token}")) - 若用IdentityServer等OIDC方案，Token过期后JS可刷新，但.NET客户端不会自动重连；需监听
connection.onclose并在重连前重新获取Token - 服务端Hub中通过
Context.User.Identity.IsAuthenticated判断登录态，但Context.User只在negotiate阶段解析一次；若Token中途过期，后续invoke仍会成功（因WebSocket已建立），需在每个Hub方法开头手动校验HttpContext.Request.Headers["Authorization"]
实际部署时最容易忽略的是传输协议协商细节和Token生命周期管理——WebSocket连接一旦建立，HTTP头就不再生效，所有认证和上下文信息都得靠初始negotiate阶段传递，后续消息本身不带身份凭证。
