.NET Core SignalR+React前端：节流网络环境下Invoke方法失效问题

我来帮你搞定这个网络慢的时候SignalR方法不生效的问题！结合你贴的前后端代码，我发现几个核心问题，咱们一步步解决：

一、后端代码的线程安全与逻辑问题 #

首先看你的AddMapping方法，这里有个隐藏的bug：当同一个id已经存在于ConnectedUsers字典中时，TryAdd并不会更新字典——它只在key不存在时才会添加。虽然List<string>是引用类型，你修改了列表内容，但如果遇到并发调用或者连接快速断开的情况，很容易出现数据不一致。另外，List本身不是线程安全的，多线程下添加/移除元素会有问题。

修复后的AddMapping方法 #

public void AddMapping(string id) {
    // 使用AddOrUpdate原子操作，保证key存在时也能更新列表
    ConnectedUsers.AddOrUpdate(
        key: id,
        // 当key不存在时，创建包含当前ConnectionId的新列表
        addValue: new List<string> { Context.ConnectionId },
        // 当key存在时，安全添加新的ConnectionId
        updateValueFactory: (key, existingList) => {
            lock (existingList) { // 给列表加锁，避免并发修改冲突
                existingList.Add(Context.ConnectionId);
                return existingList;
            }
        }
    );
}

优化OnDisconnectedAsync方法 #

原来的遍历所有Values找ConnectionId效率太低，而且同样有线程安全问题，优化后：

public override async Task OnDisconnectedAsync(Exception e) {
    // 反向查找对应key，比遍历所有Value高效
    var targetKey = ConnectedUsers.FirstOrDefault(kv => kv.Value.Contains(Context.ConnectionId)).Key;
    if (!string.IsNullOrEmpty(targetKey)) {
        lock (ConnectedUsers[targetKey]) {
            ConnectedUsers[targetKey].Remove(Context.ConnectionId);
            // 如果列表为空，移除无用的key
            if (ConnectedUsers[targetKey].Count == 0) {
                ConnectedUsers.TryRemove(targetKey, out _);
            }
        }
    }
    await base.OnDisconnectedAsync(e);
}

二、前端代码的超时与重连逻辑问题 #

网络节流下，SignalR默认的Invoke超时时间可能不够用，导致客户端误以为调用失败，触发自动重连，而此时后端可能刚执行完AddMapping，就因为连接断开触发OnDisconnectedAsync把刚加的ConnectionId删掉了，所以你看不到字典里的记录。

1. 延长Invoke超时时间并处理错误 #

给invoke方法设置更长的超时时间，同时捕获错误做重试处理：

newConnection.start().then(r => {
    fetchOrders()
    setConnectionStatus(connectingForFirstTime);
    
    const callAddMapping = () => {
        // 设置60秒超时，适配慢网络
        return newConnection.invoke("AddMapping", business.id.toString(), { timeout: 60000 })
            .then(res => {
                console.log("AddMapping成功:", res)
                setConnection(newConnection);
                setConnectionStatus(connected)
            })
            .catch(err => {
                console.error("AddMapping调用失败:", err);
                // 超时的话重试一次
                if (err.message.includes("timeout")) {
                    console.log("超时，重试AddMapping...");
                    return callAddMapping();
                }
                setConnectionStatus(off);
            });
    };
    
    callAddMapping();

    newConnection.on("neworder",(order)=>{
        // data handling
    })
    newConnection.onreconnecting(()=>setConnectionStatus(reconnecting))
    newConnection.onreconnected((connectionId)=>{
        console.log("重连成功，新连接ID:", connectionId);
        callAddMapping();
    });
    newConnection.onclose(()=>setConnection(null));
}).catch(err => setConnectionStatus(off));

2. 强制使用WebSocket传输 #

在慢网络下，WebSocket比长轮询/服务器发送事件更稳定，所以打开WebSocket传输：

const newConnection = new HubConnectionBuilder()
    .withUrl(env.realtimeBaseUrl+'orderhub', {
        skipNegotiation: true,
        transport: HttpTransportType.WebSockets
    })
    .withAutomaticReconnect()
    .build();

为什么这些修改能解决问题？ #

1. 后端原子操作+线程安全：AddOrUpdate保证了无论key是否存在，都能正确更新连接列表；加锁避免了多线程下修改List的冲突。
2. 前端超时处理：延长Invoke超时时间，避免慢网络下误判调用失败；重试逻辑保证即使一次超时，也能再次尝试。
3. WebSocket稳定性：减少慢网络下的连接断开概率，降低重连触发的频率。

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