Blazor Server线上电商应用崩溃排查及EF Core变更追踪疑问

• 基于Blazor Web App（Server Side）开发的电商系统，本地运行完全正常，但上线后每隔几天就会崩溃。崩溃时页面无限加载无法显示，必须重启应用才能恢复，持续时间从数小时到数天不等。日志显示崩溃常出现在页面被爬虫抓取时。
• 排查后怀疑问题出在EF Core：存在两个Scoped服务，会初始化EF Core DbContext实例并在Dispose()方法中销毁，这些服务仅跟踪一个实体及其子实体，且实体变更只能通过对应服务进行。
• 已知DbContext应尽可能缩短生命周期，但希望保留EF Core的ChangeTracking（UnitOfWork模式），询问是否有可行方案。
• 同时想确认该EF Core相关问题是否真的是崩溃原因；若不是，还有哪些可能的原因。
• 曾参考过类似问题的解决方案，但均无效：
  • 微软问答平台的Server相关问题
  • Stack Overflow上的Disposing相关问题

要在Blazor Server中兼顾DbContext生命周期规范和ChangeTracking（UnitOfWork模式），可以试试以下几种方案：

1. 拆分为短生命周期工作单元
   不要让Scoped服务长期持有DbContext，而是在需要执行一组连贯变更操作时，临时创建DbContext实例，完成操作后立即释放。比如封装一个UnitOfWork类，每次业务操作时实例化它，用完就Dispose：

public class UnitOfWork : IDisposable
{
    private readonly AppDbContext _dbContext;
    public UnitOfWork(AppDbContext dbContext)
    {
        _dbContext = dbContext;
    }

    public async Task SaveChangesAsync()
    {
        await _dbContext.SaveChangesAsync();
    }

    public void Dispose()
    {
        _dbContext.Dispose();
    }
}

在Blazor组件中使用时，通过IDbContextFactory<AppDbContext>创建DbContext传入UnitOfWork，用完就销毁，既保证了单操作内的ChangeTracking，又不会让DbContext长期存活。

2. 用DbContext工厂管理实例
   注册IDbContextFactory<AppDbContext>替代直接注册DbContext，这样可以按需创建独立的DbContext实例，手动管控生命周期。在Scoped服务中，每次业务操作前创建DbContext，操作完成后立即Dispose，避免服务长期持有实例：

public class ProductService
{
    private readonly IDbContextFactory<AppDbContext> _contextFactory;

    public ProductService(IDbContextFactory<AppDbContext> contextFactory)
    {
        _contextFactory = contextFactory;
    }

    public async Task UpdateProduct(Product product)
    {
        using var context = _contextFactory.CreateDbContext();
        context.Products.Update(product);
        await context.SaveChangesAsync();
    }
}

3. 限制Scoped服务内DbContext的存活范围
   如果一定要保留Scoped服务，不要在构造函数中初始化DbContext，而是只在需要跟踪实体的特定方法内创建DbContext，操作完成后立即释放，避免DbContext跟随服务全程存活。

大概率是。Blazor Server中Scoped服务的生命周期和SignalR连接绑定，爬虫抓取页面时会创建大量短连接，每个连接都会生成对应的Scoped服务实例。如果每个Scoped服务都持有一个DbContext且未正确释放，会导致数据库连接池耗尽，或者内存中堆积大量未释放的DbContext实例，最终引发应用崩溃（比如内存溢出、数据库连接超时等）。

尤其是爬虫可能并发请求多个页面，短时间内创建大量Scoped服务和DbContext，超出资源限制后，应用就无法处理新请求，表现为页面无限加载。

如果排除了EF Core的问题，还可以从以下方向排查：

• 资源泄漏：检查是否有其他未正确释放的资源，比如文件流、网络连接、第三方服务客户端等，爬虫高并发请求下这些泄漏会被快速放大。
• 内存溢出：检查是否存在内存泄漏，比如静态变量持有大量对象引用，或者缓存未设置过期策略，爬虫抓取的大量数据被长期缓存导致内存耗尽。
• 并发冲突：Blazor Server组件是单线程模型，爬虫并发请求可能引发共享资源的线程安全问题，比如未加锁的静态服务、全局状态修改等，进而导致死锁或未捕获异常。
• 服务器资源不足：上线服务器的CPU、内存、带宽不够，爬虫高并发请求下资源被耗尽，导致应用无法响应。
• 未捕获的异常：检查是否有异步操作中的异常未被正确处理，导致应用进程崩溃。可以开启更详细的日志（比如EF Core的SQL日志、Blazor的SignalR日志），或者用性能监控工具追踪崩溃前的应用状态。

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