SqlDataReader为何在Close/Dispose而非ExecuteReader阶段超时？

先讲核心认知纠正 #

你之前关于SqlDataReader的假设完全错误：

• command.ExecuteReader() 根本不会把查询的全量结果预先加载到客户端内存，它仅负责向SQL Server发送查询请求，等到服务端返回结果集元数据、或是第一行结果的传输句柄就会正常返回，不会等待整个查询跑完，也不会等所有数据传输完成。
• SqlDataReader是基于TDS协议的持续只读数据流，只有你每次调用reader.Read()时，客户端才会从网络缓冲区拉取下一行返回数据，不存在预加载全量数据的逻辑。

直接回应你的核心疑问 #

是的，你没有读完所有数据就直接关闭Reader，就是超时从ExecuteReader阶段偏移到Close阶段的直接原因。
背后的机制是SqlClient的默认行为：

• 当你没有遍历完整个结果集、没读完所有返回行就直接关闭Reader时，.NET的SqlClient不会主动打断服务端的查询执行，反而会默认持续接收网络缓冲区里剩余的、服务端已经生成的返回结果，直到把整个结果集消费完，才会真正完成Reader的关闭流程。
• 如果你的查询本身执行成本很高、返回结果量极大，当你读完第一行就break时，服务端可能还在持续执行查询、生成剩余的海量结果往网络队列里塞，这时候的关闭操作就会一直阻塞，直到触发超时阈值，最终表现为Close阶段抛超时异常。
• 而你之前设置的CommandTimeout的判定逻辑，是从命令发送到收到第一个响应的耗时——只要SQL Server能在超时时间内返回第一行的元数据，ExecuteReader()就会正常返回，完全不管后续整个查询还要跑多久、要传多少数据。

匹配你需求的实现方案 #

你的目标是验证ExecuteReader()本身能不能在超时时间内正常返回，不需要消费后续的结果，千万别在没读完数据的时候硬关Reader，要主动通知服务端终止查询：

// 提前设置你需要的命令超时时间
command.CommandTimeout = 3; // 单位为秒
SqlDataReader reader = null;
try
{
    reader = command.ExecuteReader();
    // 能走到这里就说明ExecuteReader阶段没有超时，已经达到测试目的
    // 主动向服务端发送取消指令，立刻终止正在运行的查询
    command.Cancel();
}
finally
{
    // 此时关闭Reader不会阻塞，服务端已经收到取消指令，会立刻释放查询资源
    reader?.Close();
}

补充说明 #

• 不要寄希望于Reader的自动关闭逻辑来终止服务端的查询，必须显式调用command.Cancel()才能让服务端立刻停下，否则客户端会傻等接收完所有剩余结果。
• 如果查询本身就会在执行阶段长时间无响应（比如锁等待、资源阻塞），超时依然会发生在ExecuteReader()阶段，符合你最初的测试预期。
• 上述写法可以完全避免关闭阶段的超时问题，让超时判定逻辑完全落在你想要的初始查询启动阶段。

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