ASP.NET Core+React+Redux应用中SignalR WebSocket无主动关闭却触发状态码1000正常关闭问题排查

从你的描述来看，这个“正常关闭”确实有点反常——毕竟你没有主动调用关闭方法，还已经调大了服务端超时参数。结合你提到的60 FPS发送小图片几乎占满JS线程这个核心场景，我整理了几个最可能的诱因：

• JavaScript主线程阻塞，导致心跳任务彻底无法执行
  SignalR的连接维持完全依赖客户端定时发送心跳包，而这些心跳任务是跑在JS主线程上的。如果你的应用每秒要处理60次图片发送（还要处理React+Redux的状态更新、渲染），主线程长期处于阻塞状态，SignalR的心跳定时器根本没机会触发。
  哪怕你把服务端超时拉到最大，只要客户端连心跳都发不出去，服务端会认为连接已死，主动发起正常关闭（对应1000状态码）。更糟的是，很多浏览器本身也有WebSocket的静默超时机制——如果长时间没有数据交互（包括心跳），浏览器会直接断开连接，同样返回1000。

• 浏览器后台标签页的资源节流限制
  现在主流浏览器对后台标签页的JS执行都有严格的节流策略：比如把setTimeout/setInterval的最小延迟强制拉到1秒以上，甚至暂停非关键任务。如果你的应用在多个视口（比如多个标签页）运行，后台标签页里的SignalR心跳会被严重延迟，服务端收不到心跳后就会断开连接，客户端收到的就是1000状态码的关闭通知。

• WebSocket消息频率/流量触发隐性限制
  虽然你发送的是小图片，但60 FPS的频率相当于每秒60次WebSocket消息发送。有些浏览器、反向代理服务器或者CDN会对WebSocket的消息频率、单连接总流量设置隐性阈值，当达到限制时会静默关闭连接，并且返回“正常关闭”的1000状态码（因为这是符合限制规则的主动关闭）。

• React+Redux频繁更新挤压SignalR资源
  每秒60次的图片发送必然伴随频繁的Redux状态更新和React组件重渲染，这会进一步占用主线程资源，让SignalR的心跳和连接维护任务完全排不上队。另外，如果你的Redux订阅逻辑、组件生命周期钩子和SignalR的回调存在隐性冲突（比如某个全局状态变化意外触发了连接的清理逻辑，但你没意识到），也可能导致连接被静默关闭。

• 客户端超时配置未与服务端同步调整
  你只调整了服务端的超时参数，但SignalR客户端本身也有对应的配置项：比如HubConnectionBuilder里的withAutomaticReconnect重试间隔、withUrl中的transport选项，还有客户端内置的心跳超时设置。如果客户端的超时阈值比服务端短，客户端会先判定连接失效，主动发起正常关闭（同样返回1000状态码）。

针对你的场景，给几个快速排查方向： #

1. 把图片发送逻辑移到Web Worker中，让主线程彻底解放出来处理SignalR心跳和UI渲染；
2. 暂时降低图片发送频率到30 FPS，看看连接是否能稳定维持，验证线程阻塞的猜想；
3. 检查客户端的SignalR配置，确保keepAliveIntervalInMilliseconds和服务端的KeepAliveInterval匹配，同时开启自动重连并调整重试策略；
4. 用浏览器DevTools的Performance面板录制一段会话，看主线程是否有长时间的任务阻塞，确认SignalR心跳任务的执行情况。

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