将异步任务结果从NPoco传递到Polly：哪种实现方式更优？

我在基于.NET 5.0的C#项目里，使用NPoco这款ORM框架执行SQL命令，同时希望通过Polly的重试策略（例如遇到特定临时SQL错误时最多重试N次）来包裹这些调用。同步调用的实现十分简单，但异步调用我找到了至少3种写法，本质差异在于是否混用Polly和NPoco的同步/异步方法（注：我无法查看这些方法的内部实现）。

以下所有写法均能正常编译并运行，我想知道它们在功能、可靠性或性能上是否存在差异？

代码示例 #

注：Polly策略包含同步方法：T Execute(Func<T> action)，以及异步方法：Task<T> ExecuteAsync(Func<Task<T>> action)

同步方法（使用Polly和NPoco的同步方法）： #

public T GetScalar<T>(string sql, params object[] args)
{
    return _policy.Execute(() => _npoco.ExecuteScalar<T>(sql, args));
}

异步方法#1（使用Polly和NPoco的异步方法）： #

public async Task<T> GetScalarAsync1<T>(string sql, params object[] args)
{
    return await _policy.ExecuteAsync(() => _npoco.ExecuteScalarAsync<T>(sql, args));
}

异步方法#2（使用Polly的异步方法和NPoco的同步方法）： #

public async Task<T> GetScalarAsync2<T>(string sql, params object[] args)
{
    return await _policy.ExecuteAsync(() => Task.Run(() => _npoco.ExecuteScalar<T>(sql, args)));
}

异步方法#3（使用Polly和NPoco的同步方法，以Task运行）： #

public async Task<T> GetScalarAsync3<T>(string sql, params object[] args)
{
    return await Task.Run(() => _policy.Execute(() => _npoco.ExecuteScalar<T>(sql, args)));
}

功能与可靠性 #

• 异步方法#1：这是标准的异步实现，完全遵循.NET异步编程模型。Polly的ExecuteAsync会正确处理NPoco异步方法返回的Task，重试逻辑在异步上下文执行，不会阻塞线程池线程。同时，异步SQL操作本身不会占用调用线程，能更好地利用系统资源，也能正确传递上下文（如HttpContext、取消令牌等，后续扩展时更灵活）。
• 异步方法#2：通过Task.Run将NPoco的同步方法包装成异步任务，交给Polly的异步策略执行。本质是把同步操作放到线程池线程运行，表面是异步，但NPoco的同步方法仍会阻塞线程池线程。每次重试都会新开线程池线程执行SQL调用，重试次数多的时候可能导致线程池资源消耗过高。另外，如果同步方法不支持取消，后续无法通过Polly的取消令牌终止重试流程。
• 异步方法#3：把整个Polly同步重试逻辑放到Task.Run中执行，重试过程在同一个线程池线程完成，每次重试不会新开线程，但同步SQL调用仍会阻塞该线程。和方法#2一样属于“伪异步”，没有利用异步IO的优势。如果Polly策略包含重试等待间隔，等待过程也会阻塞线程池线程，造成资源浪费。

性能 #

• 异步方法#1：性能最优，因为它利用了数据库驱动的真正异步IO操作，不会阻塞线程，高并发场景下能处理更多请求，线程池资源占用更低。
• 异步方法#2和#3：本质都是同步操作包装成异步，会占用线程池线程，高并发下线程池可能被占满，导致请求排队，性能下降。其中方法#2每次重试都会新开线程，资源消耗比方法#3更高；方法#3的重试过程在同一个线程执行，相对节省线程资源，但仍无法避免同步操作的阻塞问题。

总结 #

优先选择异步方法#1，它是真正的异步实现，符合.NET异步编程规范，在功能、可靠性和性能上都是最优解。方法#2和#3属于“伪异步”，仅适合无法使用真正异步方法的临时应急场景，不建议长期使用。

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