Blazor WebAssembly应用SignalR HubConnection刷新时触发JS错误无法建连

这个报错本质是Blazor WebAssembly 的 JS 互操作托管委托被提前 GC 回收：
报错堆栈中的invoke_delegate是 .NET WASM 运行时内置的、用于 JS 层调用 .NET 托管委托的方法。WASM 的 GC 基于 .NET 托管侧的可达性分析，只要托管委托没有被强引用保活，哪怕 JS 端还在持有这个委托的引用，.NET 端也会将其回收，这是这个报错在刷新场景下偶发的核心原因。当 JS 端（比如 SignalR 底层依赖的 WebSocket 对象）尝试调用一个已经被 .NET GC 回收的委托实例时，就会抛出这个错误。
结合你的实现和页面刷新的触发场景，具体的竞态触发逻辑如下：

• 页面刷新时，浏览器会直接打断 Blazor 组件的异步生命周期流程，不会等待你实现的DisposeAsync完整执行完成，就开始销毁 WASM 运行时。
• HubConnection内部持有多个关联 JS WebSocket 的回调委托，比如消息接收、连接关闭、自动重连相关的.NET 回调。这些委托如果没有稳定的强引用保活，在 WASM GC 触发时就会被回收，但 JS 端的 WebSocket 事件绑定还没来得及解绑，就会在页面卸载过程中触发对失效委托的调用。
• 你在OnInitializedAsync中直接启动连接但没有异常兜底，刷新过程中连接建立被中断时，部分回调引用没有被正确清理，进一步放大了竞态概率。

• 调整HubConnection的托管生命周期，不要绑定在布局组件上
  改用单例根级 DI 服务托管HubConnection实例，单例服务的生命周期和整个 WASM 运行时完全一致，不会因为局部组件的路由切换、销毁被 GC，从根源上避免组件销毁带来的引用丢失问题。
• 补全资源清理逻辑，避免残留回调引用
  除了现有的解绑Closed/Reconnected/Reconnecting内置事件的逻辑，还要在释放连接前：
  1. 移除所有通过HubConnection.On("methodName", handler)注册的客户端消息回调，避免残留的回调委托被回收
  2. 先显式调用StopAsync等待连接完全关闭、JS 端所有 WebSocket 事件解绑完成，再执行DisposeAsync释放资源，不要直接跳过停止步骤直接释放
• 修正短命委托的保活问题
  你传给WithUrl配置项的GetAccessToken是布局组件的实例方法，会捕获当前组件的this引用，一旦布局组件因为路由切换被释放，这个委托就会失去保活引用被 GC。把获取AccessToken的逻辑抽到刚才提到的单例服务中，用服务的实例方法作为AccessTokenProvider的实现，确保委托的存活周期和HubConnection完全一致。
• 针对页面刷新流程做顺序兜底
  通过 JS 互操作监听浏览器的beforeunload事件，在事件触发时先同步等待HubConnection完成停止、所有 JS 端事件解绑的流程，再允许页面执行刷新卸载，避免因为流程顺序颠倒导致的委托失效报错。
• 修正现有代码的基础问题
  你定义的_hubConnection是readonly字段却在OnInitializedAsync异步方法中赋值，建议在单例服务的构造函数中完成HubConnection的Build初始化，避免异步初始化过程中的竞态导致字段引用不完整。另外OnInitializedAsync中的StartAsync调用缺少分号，补全即可避免语法层面的潜在问题。

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