ASP.NET Core中从非异步方法调用ValueTask方法的正确方式

首先要明确：你当前用AsTask().Result的写法存在风险——会阻塞线程，甚至在特定场景下引发死锁，而且会浪费线程池资源，影响应用的并发吞吐量。

下面分两种场景给出正确处理方式：

1. 优先将调用方改为异步（最推荐） #

如果SavingChanges所在的框架/接口提供了异步版本（比如EF Core的拦截器就有SavingChangesAsync方法），这是最优解，完全符合异步编程模型：

public override async Task<InterceptionResult<int>> SavingChangesAsync(DbContext eventData, InterceptionResult<int> result, CancellationToken cancellationToken = default)
{
    var interceptionResult = await SaveChanges(eventData, result);
    return interceptionResult;
}

这种方式不会阻塞线程，能充分利用ASP.NET Core的线程池资源，避免所有异步转同步带来的问题。

2. 必须保持调用方为非异步时的处理 #

如果受限于接口或业务逻辑，必须保持SavingChanges为同步方法，那可以用GetAwaiter().GetResult()替代Result——它在异步方法抛出异常时会直接抛出原始异常，而非包装在AggregateException中，更便于调试。

你可以直接对ValueTask调用该方法，无需先转成Task：

public override InterceptionResult<int> SavingChanges(DbContext eventData, InterceptionResult<int> result)
{
    return SaveChanges(eventData, result).GetAwaiter().GetResult();
}

或者转成Task后再调用：

public override InterceptionResult<int> SavingChanges(DbContext eventData, InterceptionResult<int> result)
{
    return SaveChanges(eventData, result).AsTask().GetAwaiter().GetResult();
}

⚠️ 注意：这种方式本质还是阻塞异步代码，只有在完全没有其他选择时才使用。它会降低应用的并发能力，若SaveChanges内部依赖线程上下文相关操作，仍可能引发问题。

另外补充：ValueTask的设计目的是优化异步操作同步完成的场景，减少Task对象分配。同步调用时，无论哪种写法，都要确保不会破坏异步流程的正确性。

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