.NET中yield返回IEnumerable<Task<int>>失效问题排查

这是典型的死锁场景，核心原因是IEnumerable的延迟执行特性与同步上下文阻塞的结合导致的，具体拆解如下：

1. IEnumerable的延迟执行本质
   返回IEnumerable<Task<int>>时，Task的创建、启动逻辑不会在方法调用时立即执行，而是在枚举集合（比如调用ToArray()、遍历集合）的过程中，逐个触发yield return对应的代码。也就是说，只有当你尝试获取下一个Task时，才会运行到对应的yield return语句，生成并返回这个Task。

2. 同步上下文引发的死锁逻辑
   如果你的代码运行在拥有同步上下文的环境（比如WPF/WinForms的UI线程、老版ASP.NET的请求线程），并且Task<int>内部使用了未添加ConfigureAwait(false)的await调用，那么await完成后，会尝试回到原同步上下文线程继续执行后续代码。

当你调用Task.WaitAll时，会直接阻塞当前的同步上下文线程，等待所有Task完成。但此时，那些依赖同步上下文的Task在await结束后，无法获取被阻塞的上下文线程来完成剩余逻辑，导致Task永远处于未完成状态；反过来，WaitAll因为一直等待这些未完成的Task，也永远不会解除阻塞，形成死锁。

3. 为什么List<Task>版本正常？
   改用List<Task<int>>时，会在调用方法时就完成所有Task的创建和启动（提前枚举完所有yield return逻辑，或者直接初始化所有Task）。更关键的是，如果你的List版本中，Task的执行逻辑没有绑定到当前同步上下文（比如用Task.Run包裹异步逻辑，让后续await在ThreadPool线程上执行），就不会触发上下文依赖的死锁；即使有上下文依赖，提前枚举完成所有Task后，也不会因为枚举过程被阻塞而无法生成后续Task。

• 优先避免在同步上下文线程中使用Task.WaitAll或Task.Result这类阻塞式调用，改用await Task.WhenAll()的异步方式。
• 如果必须使用阻塞调用，在异步Task内部的await后添加ConfigureAwait(false)，避免绑定到原同步上下文。
• 提前将IEnumerable<Task<int>>转换为数组或列表（比如调用.ToArray()），确保所有Task都被创建并启动后，再执行等待操作（注意：这仅能解决延迟执行导致的Task未生成问题，无法解决上下文依赖的死锁）。

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