我的期望是这种情况，在使用 PipeOptions.Asynchronous（以及客户端）创建 NamedPipeServerStream 之后，仍然可以在管道上执行同步读/写操作。
但是，我发现当服务器同步写入超出输出缓冲区大小的字节时，客户端会阻塞读取，永远不会返回，即使服务器已经写入了适当数量的数据来满足读取。
更新：我还不能制作一个简单的重现案例，但我已经从 PipeStream 类中分离出我认为可疑的结果。我有以下代码：
byte[] buffer = new byte[ 66754 ];
int n1 = pipeStream.Read( buffer, 0, 66754 ); // Read returns 65536
int n2 = pipeStream.Read( buffer, buffer.Length - 1218, 1218 ); // Read blocks
这段代码是在管道的另一端已经写入了66754字节的数据，而读取端还没有读到这个数据的情况下执行的（注意，两端管道的in和out max buffersize为65536， 65536 + 1218 == 66754）。
当这段代码执行时，第一次读取返回 n1 == 65536，表明没有读取到我预期的所有数据，所以我执行另一次读取，询问剩余的数据。这个读取无限期地阻塞，永远不会返回。
然而，在第二次读取之前，当我检查缓冲区时，我看到了预期的写入数据，即使在 65535 位置之后！
似乎第一次读取读取了所有数据，但只返回了最大缓冲区大小，所以第二次读取挂起，因为没有更多数据要读取。但是，我不知道，因为我被错误地告知第一次读取时读取的数据量。
现在，对这段代码稍作修改。这段新代码在与之前完全相同的条件下运行。
byte[] buffer = new byte[ 66754 ];
int n1 = pipeStream.Read( buffer, 0, 65536); // Read returns 65536
int n2 = pipeStream.Read( buffer, buffer.Length - 1218, 1218 ); // Read blocks
请注意，现在第一次读取请求仅读取最大缓冲区大小 65536。在这种情况下，n1 == 65536，当第二次读取发生时，它成功返回 n2 == 1218。
在这里，不是第一次读取要求所有数据，而是要求最大缓冲区大小。这些是读取的预期正确结果。
这表明 PipeStream 代码中存在错误，它从 Read 返回了不正确的值。
我将继续尝试为此制作一个简单的复制案例。
另一个更新：发现这个： NamedPipe 的 ReadByte 挂起 似乎与我的问题有关。