Npgsql 同步多语句卡在 Receive，先看还没发出的第二条语句

服务高负载时，Npgsql 的同步 ExecuteReader() 或 ExecuteNonQuery() 长时间停在 Socket.Receive；数据库却找不到对应的完整查询。若命令包含两条或更多语句，先检查是不是后续语句尚未写出，而调用线程已经开始等回复。

这种情形与数据库执行一条慢 SQL 不同。读取端在等待，发送端却还排在线程池里。

为什么第一条写了，整批却没有发完

Npgsql 的同步多语句路径会在第一条之后把后续写入转到 ConstrainedConcurrencyScheduler。如果线程池被大量同步阻塞的请求占满，继续写入的工作可能迟迟得不到调度，最后的 Flush 也没有完成。

具体高负载记录涉及.NET 8及与Npgsql 8.0.6相符的状态机；正式10.0.3也保留这条同步多语句调度路径。它需要结合并发与线程池状态判断，不表示每个两语句命令都会卡住。

保留线程转储中的调用链、线程池队列与命令结构，避免记录参数值。只看到 Receive 无法区分服务器慢、网络无响应和客户端没发完；还应核对服务端是否收到了完整命令，以及写入状态机是否停在第二条语句附近。

沿整个调用链改为异步

优先采用 Npgsql 的异步接口，并让上层请求一路 await，不要在最后用 .Result、.Wait() 或 GetAwaiter().GetResult() 又阻塞回去。下面展示已有参数化命令的执行边界：

await using var reader = await command.ExecuteReaderAsync(cancellationToken);
do
{
    while (await reader.ReadAsync(cancellationToken))
    {
        ConsumeCurrentRow(reader);
    }
} while (await reader.NextResultAsync(cancellationToken));

command 由项目原有连接和事务创建，ConsumeCurrentRow 是应用自己的行处理函数。多结果集要完整处理或按已有规则结束读取，不能只处理第一组结果就假定整批工作完成。

Task.Run(() => command.ExecuteNonQuery()) 仍会占用线程执行同步I/O，不是这条改造的等价替代。单纯调大线程池最小线程数或连接池上限，也不能消除同步等待；更高并发还可能把数据库与线程池一起压满。

如果暂时只能调整少量路径，先限制并发进入同步数据库操作的数量，给出明确排队和失败策略。拆开多语句只能在业务允许时采用，并保留原事务的原子性和结果顺序；不能把一个必须一起提交的batch拆成多个自动提交操作。

验证的是发送与资源回收

在获准的负载环境检查线程池等待、数据库实际执行、请求完成以及连接归还。覆盖多语句、单语句对照、取消和异常路径，确认没有漏读结果或把活动reader的连接提前交回池。

目前不能仅凭换到一个较新的Npgsql版本就宣布此类同步batch调度已消失。即使代码注释提到避免线程池依赖，也要以实际实现和请求链为准。