为何将方法签名改为Task<bool>时Entity Framework会在SaveChanges处挂起？

你遇到的这个挂起问题，核心原因大概率是异步操作被同步阻塞导致的死锁，结合你给出的两段代码，我们来拆解细节：

核心差异对比 #

先看两段代码的关键不同：

1. 返回值类型：第一段返回Task<bool>，第二段返回Task
2. 异常处理：第一段在catch中返回false，第二段直接throw异常

为什么第一段代码会挂起？ #

最常见的场景是：你在同步代码中用.Result或.Wait()来等待SaveAsync的结果。比如这样的调用方式：

// 同步方法中调用异步方法，用.Result阻塞等待
bool result = SaveAsync(agency).Result;

在ASP.NET传统框架、WinForms/WPF这类有SynchronizationContext的环境中，await默认会捕获当前上下文，当SaveChangesAsync完成后，需要回到这个上下文继续执行return true/false的逻辑。但此时你的主线程已经被.Result阻塞，占用了这个上下文，导致异步任务完成后无法回到上下文继续执行，最终形成死锁，看起来就是SaveChangesAsync一直挂起。

那为什么第二段代码能正常运行？

• 如果你的调用方式是正确的await SaveAsync(agency)，那两段代码都应该正常；但如果是用.Result调用，第二段代码在抛出异常时会直接中断阻塞，不会进入死锁的等待循环，所以看起来正常。不过这只是表象，本质上同步调用异步方法的方式本身就有问题。

解决办法 #

1. 优先使用await调用异步方法（推荐） #

永远遵循异步编程的"全程异步"原则，把调用SaveAsync的方法也改成异步，用await等待结果：

// 调用方也改成异步方法
public async Task SomeCallingMethod()
{
    var agency = new agency();
    bool result = await SaveAsync(agency);
    // 后续逻辑
}

2. 用.ConfigureAwait(false)避免捕获上下文 #

如果暂时无法修改调用方的同步逻辑，可以在await时加上.ConfigureAwait(false)，告诉框架不需要回到原来的上下文执行后续代码，从而避免死锁：

public async Task<bool> SaveAsync(agency agency) 
{ 
    using (var ctx = new AvnEntities()) 
    { 
        try 
        { 
            ctx.agencies.Add(agency); 
            // 加上ConfigureAwait(false)
            await ctx.SaveChangesAsync().ConfigureAwait(false); 
            return true; 
        } 
        catch (System.Exception ex) 
        { 
            // 建议添加日志记录，不要直接吞掉异常
            // Logger.Error(ex, "保存agency失败");
            return false; 
        } 
    } 
}

3. 避免吞掉所有异常 #

第一段代码中直接捕获所有异常并返回false的做法非常不推荐——这会隐藏真正的错误原因（比如实体验证失败、数据库连接异常等），调试时很难定位问题。至少要记录异常日志，或者在特定场景下只捕获预期的异常类型。

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