ASP.NET Core 6中控制器返回的IQueryable是否会被异步枚举？

我的问题与历史上两个关于Web API异步查询的讨论方向相关，核心是验证社区资深开发者（包括Stephen Cleary）提出的无需显式对IQueryable执行异步枚举的观点在当前ASP.NET Core版本下是否成立。
已知在近期版本的ASP.NET Core中，控制器返回IAsyncEnumerable类型结果时，框架会自动对其执行异步枚举，我需要明确两个核心疑问：

• 框架对IQueryable类型的返回值，是否采用和IAsyncEnumerable完全一致的异步处理逻辑？
• 已知IAsyncEnumerable无缓冲流式传输存在潜在问题，这类问题是否同样存在于返回IQueryable的场景中？

一、IQueryable返回值的框架处理逻辑 #

在ASP.NET Core 3.0及以上版本的默认Web API实现中，框架对IQueryable的处理和直接返回IAsyncEnumerable的逻辑并不完全相同：

• 当控制器直接返回IQueryable时，输出格式化器会首先检测当前IQueryable是否实现了IAsyncEnumerable<T>接口，EF Core等主流ORM返回的IQueryable默认都实现了该接口。满足条件时，格式化器会优先调用异步枚举接口执行查询，整个过程不会阻塞请求线程。
• 和直接返回IAsyncEnumerable的默认行为不同，默认配置下返回IQueryable不会自动开启无缓冲流式传输：系统会先完成全量查询结果的枚举，完成序列化前置缓冲后再向客户端返回响应，只有显式开启响应流式传输配置时，才会逐行枚举、逐段输出内容。
• 如果返回的IQueryable未实现IAsyncEnumerable<T>（比如内存集合通过AsQueryable()转换得到的结果），框架会自动降级为同步枚举执行，不会抛出异步相关异常。

从实际执行逻辑来看，“无需手动对IQueryable执行显式异步枚举”的观点在当前版本下依然成立：只要使用的是原生支持异步枚举的ORM提供的IQueryable，框架会自动处理异步执行逻辑，不需要额外手动调用ToListAsync()之类的方法。反过来，手动提前调用ToListAsync()会强制完成全量查询，反而会损失框架自带的查询优化、错误拦截能力。

二、无缓冲流式传输问题的影响范围 #

IAsyncEnumerable无缓冲流式传输的所有潜在问题，在IQueryable开启流式响应的场景下会完全复现，典型问题包括：

• 查询执行到中途抛出异常时，由于响应头已经提前发送、HTTP状态码已经设置为200，无法再向客户端返回正确的错误状态码，只能中断连接，导致客户端收到不完整响应
• 序列化过程中如果出现对象循环引用、属性序列化失败等问题，同样无法在响应发送前拦截，会直接导致连接中断
• 由于查询和序列化逐段执行，整个请求的执行周期会被拉长，如果数据库连接超时、请求超时的配置不匹配，很容易出现连接被意外释放、查询中途终止的问题

如果没有显式开启IQueryable的流式响应配置，上述问题都不会出现：框架会先完成全量查询和序列化缓冲，所有异常都会在响应头发送前被捕获，按照正常错误处理逻辑返回对应状态码。

三、实践建议 #

• 普通业务场景下直接返回IQueryable即可，不需要手动调用ToListAsync()，框架会自动处理异步枚举逻辑
• 如果需要通过无缓冲流式传输返回大结果集，优先显式返回IAsyncEnumerable<T>，同时要做好中途异常的兜底处理，不要依赖默认错误中间件处理流式场景下的异常
• 不要将内存集合转换的IQueryable直接返回，这类实现不会走异步枚举路径，高并发场景下可能引发线程池饥饿问题

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