使用Task.Run处理IO绑定任务以避免修改方法签名的技术疑问

疑问1：这种阻塞是否轻微到足以维持现有代码，避免修改所有调用方法的签名以添加async/await？ #

• 得结合业务场景和并发量判断：如果Redis操作耗时极短（几毫秒级别）且系统并发量低，短期可能不会出问题。但ASP.NET的线程池线程是核心资源，一旦并发上来，大量线程被Wait()阻塞，会导致后续请求排队等待可用线程，直接拉低系统吞吐量。
• 另外这种「同步包裹异步」的写法本身就是反模式，不仅浪费线程资源，还可能在特定同步上下文下引发死锁。如果业务有扩容计划，或者已经出现请求延迟上升的情况，建议逐步改成全异步写法：先把Save改成async Task，再从调用栈最上层开始逐步调整，不用一次性改完，慢慢迭代即可。

疑问2：仅在委托中await了transaction.ExecuteAsync，它是否会在上方的Task完成前运行？ #

• 不会。Task.Run里的异步委托会按流程执行：先创建事务，调用StringSetAsync和SetAddAsync（这两步是发起异步请求但未等待完成），然后await transaction.ExecuteAsync——这一步会等待整个Redis事务执行完成（包括前面两个异步操作的结果）。只有当ExecuteAsync执行完毕，整个委托才会结束，上方的Task才算完成。所以Wait()会一直阻塞到整个Redis事务处理完成才释放调用线程。

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