Npgsql 请求已取消，连接池取出的命令却等到超时才结束

CancellationToken 三秒后已经取消，Npgsql 命令却继续等了几十秒才结束。若这是从池里复用连接后的第一条命令，而服务器或链路保持TCP连接却不再回复，应检查会话重置的预置消息阶段。

在 Npgsql 10.0.3 中，池连接归还后的会话重置可以随下一条命令一起发送。用户查询开始读取结果前，驱动需要先读完这些预置回复，其中可能包括 DISCARD ALL。

取消请求可能还没进入用户查询阶段

这条路径用 ReadingPrependedMessagesMRE 判断预置回复是否读完。尚未读完时，立即用户取消会先被记录，延后处理，以免取消请求误伤会话重置。

如果服务器一直不回复，延后处理也等不到继续执行的条件。请求侧token已取消，与驱动已经结束这次I/O，是两项不同状态。此时等待可能主要受命令超时及后续取消连接过程影响。

排查应比较新建连接与复用连接、第一条命令与后续命令，以及服务端是否在返回会话重置回复。没有这些证据时，不能把所有“取消慢”都归到 DISCARD ALL；应用阻塞线程、握手和普通慢查询也会造成类似等待。

为驱动设置有限的等待策略

继续传入调用方的 CancellationToken，同时给实际执行的命令设置符合业务预算的非零 CommandTimeout。例如下面只展示配置位置，秒数是示例：

await using var command = new NpgsqlCommand(sql, connection);
command.CommandTimeout = 5;
var result = await command.ExecuteScalarAsync(cancellationToken);

sql 应是项目已有的只读或参数化查询，connection 已按原有方式取得。不能为了适配这个示例把实际写入逻辑改成另一条查询。

连接串中的 Timeout 控制建连等待，Command Timeout 是命令等待，Cancellation Timeout 还影响取消后的等待过程，单位和作用不同。配置有限命令超时能提供驱动侧的另一道失败机制，但不能保证请求一定在精确五秒内结束：网络、取消协商与当前状态仍有额外影响。

若业务有严格请求期限，应让调用方清楚区分“停止等待结果”和“数据库操作已确认结束”。不要用 Task.WhenAny 返回后立即把仍在执行的连接交回共享池，也不要并行在同一连接发另一条查询。

保留池连接的会话隔离

No Reset On Close=true 可能绕过这类重置路径，却会改变池连接复用时的会话清理，带来设置或状态泄漏风险。它不能作为普通业务应用的通用修复。关闭GSS加密也不是修复会话重置取消的必要步骤。

发生异常后，由原有 await using 生命周期等待资源处置，检查连接最终状态；不要把已断开的连接手工标成可复用。写命令还需要按业务幂等与提交确认规则处理，客户端超时本身不证明服务器没有执行。

在隔离环境覆盖正常返回、服务器无响应、调用方取消和命令超时。核对实际结束时刻与池资源回收，保留重置后的会话约束，不把“页面先返回了”当作数据库任务已经安全结束。