.NET Core Blazor Server 订单后台瞬时服务的生命周期管控咨询

你现在的实现方案，本质上混淆了Blazor依赖注入的生命周期边界，才会出现服务不受控的问题：

• Blazor Server原生的三种DI生命周期，全部是和SignalR连接的作用域强绑定的：Scoped服务的存活期和单用户的SignalR连接完全一致，连接断开作用域就被整体回收；Transient服务每次解析都会新建实例，但实例同样归属当前的DI作用域，作用域销毁时所有关联的实例都会被释放。
• 你之前误以为Transient能实现每个订单的独立服务，本质是对其生命周期的误解——它并不是“独立运行的后台服务”，只是“每次解析就新建，随所属作用域销毁而销毁”的服务，根本达不到跨页面、跨连接常驻运行的要求。
• 你把OrderManagementService注册为Transient，再从Razor组件直接注入，相当于把这个订单服务的存活期和用户当前打开的页面、当前的SignalR连接完全绑死：用户关了页面、断了连接，服务就会被意外终止；如果服务内部持有了不被作用域追踪的强引用，又会因为没有统一回收逻辑，出现实例长期驻留占用资源的问题。

你之前观察到的生命周期完全失控的状态，核心就是没有为订单服务建立独立于Blazor连接的托管机制，既没有跨连接的强引用持有，也没有统一的资源回收入口。

这个场景下，直接把订单服务注册为Transient给组件注入完全不适用，你需要搭建一套应用级独立托管的订单服务管理机制，完全脱离Blazor页面的生命周期：

1. 实现单例的订单服务托管器 #

• 这个托管器本身作为全局单例存在，生命周期和整个Blazor应用一致，不受用户连接、页面开关的影响。
• 托管器内部维护线程安全的订单服务实例字典，键为唯一订单ID，值为对应订单的专属服务实例，同时负责实例的创建、校验、释放全流程。
• 参考核心实现代码：

// 托管器注册方式：services.AddSingleton<OrderServiceHost>();
public class OrderServiceHost
{
    // 线程安全字典存储所有活跃的订单服务实例，保证强引用不会被GC回收
    private readonly ConcurrentDictionary<string, OrderManagementService> _activeServices = new();
    private readonly ILogger<OrderServiceHost> _logger;
    private readonly IServiceProvider _rootProvider;

    public OrderServiceHost(ILogger<OrderServiceHost> logger, IServiceProvider rootProvider)
    {
        _logger = logger;
        _rootProvider = rootProvider;
    }

    // 创建/获取指定订单的专属服务实例
    public OrderManagementService GetOrCreate(string orderId)
    {
        return _activeServices.GetOrAdd(orderId, id => 
        {
            // 为每个订单服务创建独立的DI作用域，不共用Blazor的用户连接作用域
            var scope = _rootProvider.CreateScope();
            return new OrderManagementService(
                orderId,
                scope.ServiceProvider.GetRequiredService<ITrackingService>(),
                scope.ServiceProvider.GetRequiredService<ILogger<OrderManagementService>>()
            );
        });
    }

    // 主动释放指定订单的服务实例
    public async Task Release(string orderId)
    {
        if(_activeServices.TryRemove(orderId, out var service))
        {
            // 先停止服务内部的后台追踪任务
            await service.StopTrackingAsync();
            // 释放服务关联的所有资源
            (service as IDisposable)?.Dispose();
            _logger.LogInformation("订单{OrderId}的专属管理服务已释放", orderId);
        }
    }

    // 兜底扫描逻辑：定时清理异常驻留的超时实例
    public void StartSweepLoop()
    {
        // 后台每10分钟扫描一次，对超过预设最长运行时长、无活跃追踪任务的实例做强制回收兜底
    }
}

2. 调整依赖注册配置 #

• 移除原本针对OrderManagementService的直接Transient组件注入逻辑；如果托管器内部需要为服务解析依赖，可以保留OrderManagementService的Transient注册，供托管器创建独立作用域时使用——绝对不要让Razor组件直接注入OrderManagementService本身。
• 给Razor组件仅注入单例的OrderServiceHost，需要获取当前订单服务实例时，通过托管器的GetOrCreate方法拿到对应实例即可。

3. 打通全链路的生命周期触发逻辑 #

• 新订单创建完成时，主动调用托管器的GetOrCreate方法传入订单ID，启动该订单的专属追踪服务，从这一刻开始，服务的运行完全和用户开不开页面、连不连SignalR没有关系。
• 当订单状态流转到“已完成”“已取消”等终态时，不管是哪个用户、哪个页面触发的状态变更，直接调用托管器的Release方法，释放对应实例的所有资源。
• 托管器内置定时扫描兜底逻辑，对异常未触发回收、长期驻留的实例做强制清理，避免出现资源泄漏。

• 不要把OrderManagementService直接注册为Singleton，否则所有订单会共用同一个服务实例，完全达不到“每个订单独立专属服务”的要求。
• 不要把订单服务的实例引用存在Razor组件的页面状态里，否则一旦组件被释放、SignalR连接断开，你持有的引用会丢失，又会回到“实例不受控”的老问题——所有实例的强引用，必须存在单例的托管器中统一管理。
• 注意Blazor Server的预渲染场景，不要在预渲染阶段触发订单服务的创建逻辑，否则会出现预渲染流程结束后，实例没有被正确留存的问题。

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