SignalR Core Reconnected事件触发后Hub状态异常咨询

首先要明确：SignalR Core的Reconnected事件触发时机是重连请求已成功完成，但客户端内部状态流转存在短暂延迟，所以会出现事件触发时HubConnection.State仍处于Connecting的情况——这是内部状态更新的时序问题，而非重连失败。

以下是比循环等待更优的方案：

1. 使用官方内置的WaitForStateAsync方法（推荐） #

从.NET 6开始，HubConnection提供了WaitForStateAsync异步方法，专门用于等待连接进入指定状态，无需自己实现轮询逻辑：

hubConnection.Reconnected += async (connectionId) =>
{
    // 等待连接状态变为Connected，超时可自定义（默认无超时）
    await hubConnection.WaitForStateAsync(HubConnectionState.Connected);
    
    // 执行重连后的业务操作
    await hubConnection.SendAsync("NotifyReconnected", connectionId);
};

这个方法内部已处理了状态监听和异步等待，性能更优且代码简洁。

2. 订阅StateChanged事件监听状态流转 #

如果使用的是.NET 6之前的版本，可以通过订阅StateChanged事件，精准捕获从Connecting到Connected的状态变化：

hubConnection.StateChanged += (stateChange) =>
{
    if (stateChange.OldState == HubConnectionState.Connecting 
        && stateChange.NewState == HubConnectionState.Connected)
    {
        // 重连完成，执行操作（注意异步操作要避免阻塞，用_ = ... 或await）
        _ = HandleReconnectedAsync(hubConnection);
    }
};

// 单独的异步处理方法
private async Task HandleReconnectedAsync(HubConnection hub)
{
    await hub.SendAsync("NotifyReconnected", hub.ConnectionId);
}

这种方式直接依赖状态变更的可靠信号，比在Reconnected事件中轮询更稳定。

3. 避免直接依赖State属性，利用Reconnected事件参数 #

如果你的业务逻辑只需要确认重连成功，不需要严格依赖Connected状态，可以直接使用Reconnected事件返回的connectionId（重连后的新连接ID）作为成功标识，跳过状态判断：

hubConnection.Reconnected += async (connectionId) =>
{
    // connectionId非空即表示重连成功
    if (!string.IsNullOrEmpty(connectionId))
    {
        await hubConnection.SendAsync("NotifyReconnected", connectionId);
    }
};

为什么不推荐循环等待？ #

手动循环等待会浪费CPU资源，若使用同步循环还可能阻塞调用线程；即使是异步循环，也需要自己处理超时、取消等边界情况，不如官方方法或状态监听可靠。

内容的提问来源于stack exchange，提问作者fpdave100