Scoped服务中未用await的Blob异步上传：可靠性及优化方案咨询

为避免用户等待Blob上传完成，我在Scoped生命周期的BlobService异步方法UploadBlobAsync调用时未使用await关键字，API方法为同步实现。测试中Blob上传成功，但担忧Scoped服务会随API请求处理完成被释放，导致上传中断。请问：

1. 该方式是否始终可靠？
2. 若可靠，为何服务释放不会终止未完成的上传？
3. 是否应采用临时保存文件+后台作业上传的方案来提升API响应速度？

相关代码 #

API 代码 #

[HttpPost("upload")]
public void Upload(Model model)
{
   // 未使用await关键字，因此Upload API方法是同步的
   // 尽管内部的UploadBlobAsync服务方法是异步的
   _blobService.UploadBlobAsync("uploads", model.name, GetBytes(model.file));  
}

BlobService 代码 #

public class BlobService : IBlobService
{
   public async Task UploadBlobAsync(string container, string blobName, byte[] data)
   {
      var blobContainerClient = this.blobServiceClient.GetBlobContainerClient(container);
      BlobClient blobClient = blobContainerClient.GetBlobClient(blobName);
      await blobClient.UploadAsync(new BinaryData(data), true);
   }
}

Startup 配置代码 #

builder.Services.AddScoped(x => new BlobServiceClient(storageConnStr));
builder.Services.AddScoped<IBlobService, BlobService>();

1. 该方式并不始终可靠 #

这种“火并忘记”的异步调用存在明确风险：

• Scoped服务释放可能中断上传：若BlobService或其依赖的BlobServiceClient在上传过程中被释放，可能触发对象回收时的异常，直接终止上传。
• 未捕获异常会导致问题：如果UploadBlobAsync内部抛出异常（如网络中断、权限错误），由于没有await也未处理异常，.NET Framework时代会直接终止进程；.NET Core/5+虽不会终止进程，但异常会完全丢失，无法排查上传失败原因。
• 进程/应用池回收会终止任务：API请求完成后，若应用池触发回收或进程重启，未完成的上传会被强制终止。

2. 测试中上传成功的原因 #

你测试时能成功，只是巧合：

• 上传操作完成速度快，在Scoped服务被释放前就已执行完毕。
• .NET垃圾回收不会立即回收标记为释放的对象，只要上传操作还在引用这些对象，它们会暂时存活到操作完成。但GC回收时机完全不确定，不能依赖这种行为保证上传可靠性。

3. 推荐采用临时保存文件+后台作业的方案 #

这是兼顾响应速度和可靠性的最优解：

• 大幅提升API响应速度：API仅需接收文件并保存到本地临时存储（或分布式缓存），即可立即返回响应，用户无需等待Blob上传完成。
• 保证上传可靠性：后台作业可实现重试机制，即使单次上传失败也能自动重试；且后台作业生命周期独立于API请求，不受应用池回收或请求结束影响。
• 便于监控排查：后台作业可记录详细日志、跟踪上传状态，出现问题时能快速定位。

如果暂时不想引入复杂的后台作业框架，也可以用IHostedService实现简单的任务队列，将上传任务加入队列后API立即返回，由后台服务处理上传。

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