异步方法因未等待任务阻塞的问题及优化方案咨询

这个问题的核心在于当await一个已经完成的Task时，代码会同步继续执行——你的FakeTask返回的是Task.FromResult(false)，这是一个已完成的Task，所以整个RunAsync的循环会变成同步执行，完全没有“异步出去”，导致调用RunAsync后直接阻塞在同步循环里，后续代码根本没机会并行执行，甚至取消令牌都来不及触发。

下面给你几个更优雅的解决思路：

1. 用Task.Yield()强制异步启动（最直接的替代方案） #

Task.Yield()的作用是主动让出当前的执行上下文，把后续的操作放到调度队列中，确保RunAsync方法在首次await后立即返回给调用者，让后续代码可以并行执行。它比Task.Delay(1)更轻量，也更符合“强制异步”的语义：

private async Task RunAsync(CancellationToken cancel) { 
    bool finished = false; 
    // 强制让出执行上下文，确保方法异步启动
    await Task.Yield();
    while (!cancel.IsCancellationRequested && !finished) 
        finished = await FakeTask(); 
}

这样调用RunAsync后，会立即返回一个未完成的Task，后续代码可以正常执行，不会被阻塞。

2. 让Mock的FakeTask返回真正异步的Task（单元测试场景最优） #

既然问题出在单元测试中Mock的FakeTask是同步完成的，那我们可以让它返回一个真正需要异步等待的Task，这样既模拟了真实场景（你实际项目中用Task.Delay是异步的），又能正确测试取消逻辑：

简单版：用Task.Run包装 #

// 单元测试中的FakeTask实现
private Task<bool> FakeTask() {
    // 让任务在ThreadPool上执行，确保异步性
    return Task.Run(() => false);
}

灵活版：用TaskCompletionSource控制任务完成时机 #

如果需要更精细地控制FakeTask的完成时机（比如先触发取消令牌，再让任务完成，验证取消逻辑），可以用TaskCompletionSource：

private TaskCompletionSource<bool> _fakeTaskTcs;

// 单元测试中的FakeTask实现
private Task<bool> FakeTask() {
    _fakeTaskTcs = new TaskCompletionSource<bool>();
    return _fakeTaskTcs.Task;
}

// 在测试中可以这样操作：
var cancelSource = new CancellationTokenSource();
var task = RunAsync(cancelSource.Token);
// 先触发取消
cancelSource.Cancel();
// 再完成FakeTask
_fakeTaskTcs.SetResult(false);
// 验证任务是否已取消
await Assert.ThrowsAsync<TaskCanceledException>(() => task);

这种方式完全模拟了真实场景的异步行为，测试逻辑也更严谨。

3. 重构循环逻辑（备选方案） #

如果不想修改方法开头，也可以在循环内部确保每次迭代都有异步点，比如用Task.Run包装FakeTask的调用：

private async Task RunAsync(CancellationToken cancel) { 
    bool finished = false; 
    while (!cancel.IsCancellationRequested && !finished) {
        // 确保每次迭代都异步执行
        finished = await Task.Run(() => FakeTask().Result, cancel);
    }
}

不过这个方案会额外占用ThreadPool线程，不如Task.Yield()轻量，所以优先级低于前两个方案。

总结一下：如果只是要解决“同步阻塞”的问题，Task.Yield()是最优雅的替代；如果是单元测试场景，推荐让Mock返回真正异步的Task，这样测试逻辑更贴近真实业务。

内容的提问来源于stack exchange，提问作者B. Ball