为什么BackgroundService.ExecuteAsync内的阻塞调用不会阻塞主线程？

你的疑问本质是对异步续体调度规则和ASP.NET Core的运行机制存在两个认知偏差，具体原因如下：

1. ASP.NET Core 不存在自定义同步上下文 #

你之前认为「await续体会在原始调用的同步上下文上执行」的结论，仅适用于存在自定义同步上下文的场景（比如WinForm/WPF桌面应用、.NET Framework时代的旧ASP.NET）。ASP.NET Core从首个版本开始就完全移除了自定义同步上下文，全局的SynchronizationContext.Current永远为null。
按照TAP的默认调度规则：如果await时没有捕获到非默认的同步上下文，await后的续体代码会直接被调度到线程池的任意空闲线程上执行，完全不会占用触发ExecuteAsync的原始线程，自然也不可能阻塞应用主线程。

2. BackgroundService的启动逻辑本身就是「发完即忘」 #

你贴的StartAsync源码已经明确了执行逻辑：

public virtual Task StartAsync(CancellationToken cancellationToken)
{
    // Store the task we're executing
    _executingTask = ExecuteAsync(_stoppingCts.Token);

    // If the task is completed then return it, this will bubble cancellation and failure to the caller
    if (_executingTask.IsCompleted)
    {
        return _executingTask;
    }

    // Otherwise it's running
    return Task.CompletedTask;
}

当ExecuteAsync执行到第一个await（你示例中的await Task.Yield()）时，方法会立即返回未完成的Task，此时_executingTask.IsCompleted为false，StartAsync直接返回Task.CompletedTask，宿主的启动流程会继续往下走，完全不会等待ExecuteAsync的后续逻辑执行。你示例中阻塞的Foo()调用完全是在线程池线程上独立运行的，最多只会占用一个线程池线程，不会影响主线程运行或者其他接口请求的处理。

补充说明 #

哪怕你删掉示例中的await Task.Yield()，直接在ExecuteAsync开头就调用阻塞的Foo()，也不会卡住整个应用：ASP.NET Core宿主启动所有IHostedService的StartAsync方法时，本身就会将逻辑调度到线程池执行，最多只会拖慢服务的启动速度，不会阻塞主进程。不过这种同步阻塞的写法会浪费线程池资源，高并发场景下可能导致线程池饥饿，还是建议尽量将阻塞调用改造为异步实现。

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