在异步ASP.NET Core代码中使用Any而非AnyAsync的原因探讨

在微软ASP.NET Core搭配EF Core的Web API教程中，PutTodoItem这个异步方法处理并发异常时，调用了同步的TodoItemExists方法：

[HttpPut("{id}")]
public async Task<IActionResult> PutTodoItem(long id, TodoItem todoItem)
{
    if (id != todoItem.Id)
    {
        return BadRequest();
    }

    _context.Entry(todoItem).State = EntityState.Modified;

    try
    {
        await _context.SaveChangesAsync();
    }
    catch (DbUpdateConcurrencyException)
    {
        if (!TodoItemExists(id))
        {
            return NotFound();
        }
        else
        {
            throw;
        }
    }

    return NoContent();
}

private bool TodoItemExists(long id)
{
    return _context.TodoItems.Any(e => e.Id == id);
}

既然PutTodoItem本身是异步方法，为什么不改用异步版本的查询方法？比如：

private async Task<bool> TodoItemExistsAsync(long id)
{
    return await _context.TodoItems.AnyAsync(e => e.Id == id);
}

教程里采用同步写法主要出于教学简化和场景适配的考量：

• 优先保证示例简洁：教程的核心目标是让初学者快速理解Web API的PUT请求流程、EF Core实体状态管理以及并发异常处理逻辑。引入异步方法会额外增加await关键字和方法签名的变化，多出来的异步细节会分散新手对核心知识点的注意力，同步写法能让代码逻辑更直观易懂。

• 同步操作的影响可忽略：TodoItemExists里的Any方法会被EF Core转换为高效的EXISTS SQL查询，执行速度极快，几乎不会占用线程资源。这种毫秒级的操作，异步带来的线程利用率提升非常有限，反而会产生少量异步状态机的额外开销，在教学场景下完全没必要。

• 生产环境可灵活替换：如果是实际项目，尤其是高并发场景下，把这个方法改成AnyAsync的异步版本是更规范的做法，能更好地遵循ASP.NET Core的异步编程最佳实践。教程只是选择了最适合入门教学的简化方案。

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