Blazor Server：优雅处理Circuit断开连接问题

一、你的设计不存在问题 #

在Blazor Server中，将服务注册为scoped以绑定到单个Circuit实例是标准且合理的做法——单例服务无法隔离用户上下文，瞬态服务则会因重复创建Circuit级状态造成资源浪费，所以不用怀疑自身设计的正确性。

二、直接应对异常的实用策略 #

• 全局捕获与静默处理：在应用启动配置中添加全局异常处理逻辑，针对ObjectDisposedException、JSDisconnectedException这类与Circuit断开相关的异常，仅记录日志而不向用户端抛出错误。比如在Mediator的预处理/后处理管道中加入异常捕获逻辑，或者利用Blazor的错误边界组件包裹页面，过滤此类异常。
• 操作前的松散状态检查：在关键业务操作执行前，可尝试通过注入的CircuitAccessor或检查scoped服务的状态做预判断，但需注意CircuitRegistry的状态检测并非绝对精准，因此捕获异常仍是更可靠的兜底方案。
• DotNetObjectReference的针对性处理：在组件的Dispose方法中主动调用DotNetObjectReference.Dispose()释放资源；同时在JS回调逻辑中，若触发.NET端方法时出现异常，及时清理JS侧的引用绑定，避免后续无效调用。

三、架构层面的规避方案 #

• 剥离长时操作到后台服务：将耗时的业务逻辑（如批量数据处理、第三方接口调用）从Circuit上下文转移到单例后台服务（如IHostedService实现），前端仅负责提交任务请求和轮询/接收结果推送。这样即使Circuit断开，后台操作不受影响，也不会因scoped服务释放抛出异常。
• 解耦状态与业务服务：将Circuit级的用户状态单独存储在scoped容器中，业务服务注册为瞬态或单例，服务执行时仅接收状态作为参数，不持有scoped状态的引用。这种设计下，即使scoped状态被释放，业务服务本身仍能正常工作，异常也更易定位和处理。
• 利用Circuit生命周期钩子终止操作：自定义CircuitHandler并注册到DI容器，订阅CircuitDisconnected事件；在业务操作中传入关联的CancellationToken，当收到Circuit断开通知时，触发令牌取消，主动终止正在执行的异步操作，避免后续访问已释放资源。

四、行业普遍处理方式 #

多数成熟的Blazor Server项目都会遇到此类问题，普遍的处理思路是：

• 对Circuit断开相关异常做全局捕获+日志留存，不向用户展示错误（用户此时已离开页面，无实际意义）。
• 优先采用后台异步处理+前端状态同步的模式，减少Circuit上下文内的长时操作，从根源降低异常发生概率。
• 不追求“零异常”，因为用户断连、关闭浏览器属于不可控的正常行为，只要不影响系统稳定性、不产生脏数据，少量此类异常日志是可接受的。

内容的提问来源于stack exchange，提问作者Matthias Müller