使用signalr_netcore的Flutter客户端处理ASP.NET Core后端重启异常求助

• 清理旧连接关联状态
  后端重启后，服务器端旧连接已完全失效，但如果客户端重连后，业务代码仍持有旧的Hub代理实例、或用户-ConnectionId映射未更新，会导致后续Hub调用指向无效资源，积累请求后引发/_negotiate超时。

  • 客户端重连成功拿到新ConnectionId后，立即替换所有业务逻辑中使用的旧Hub实例，更新用户与ConnectionId的绑定关系（比如在线用户列表、消息订阅通道）。
  • 后端Hub的OnDisconnectedAsync方法中，务必彻底移除当前ConnectionId关联的所有业务数据（如从Redis/内存缓存中删除用户连接记录），避免旧数据干扰新连接逻辑。

• 调整SignalR客户端重连策略
  Flutter SignalR包的自动重连配置不合理可能导致服务器重启初期请求过载：

  • 确认开启AutomaticReconnect，并合理设置重试间隔（比如withAutomaticReconnect([0, 2, 10, 30])），避免短时间内大量重试请求冲击刚启动的服务器。
  • 重连成功后，必须重新订阅所有Hub方法（比如之前调用的hubConnection.on("ReceiveNotification", ...)），未订阅会导致功能看似异常。
  • 避免复用旧的HubConnection实例，重连失败或服务器重启后，直接创建新的实例发起连接。

• 优化后端SignalR配置
  检查ASP.NET Core SignalR的超时与生命周期配置，确保和客户端匹配：

  builder.Services.AddSignalR(options =>
  {
      options.ClientTimeoutInterval = TimeSpan.FromSeconds(30); // 客户端超时时间
      options.KeepAliveInterval = TimeSpan.FromSeconds(10);    // 心跳间隔
      options.MaximumReceiveMessageSize = 1024 * 1024;         // 根据业务调整消息大小
  });
  

  • 同时检查Kestrel服务器的连接限制配置，比如最大并发连接数、请求超时时间，避免服务器重启后连接池未就绪导致请求超时。

• 排查客户端HTTP客户端状态
  Flutter SignalR内部的HTTP客户端可能存在状态残留：

  • 重连时确保重置HTTP客户端实例，避免旧实例持有失效的连接池或缓存的旧服务器地址。
  • 检查客户端网络环境，确认后端重启后服务器地址、端口未变更，无防火墙/代理拦截/_negotiate请求。

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