我知道之前的两个答案都在告诉你，但我会重复它们并添加一些我的东西：如果后续发送之间有足够的时间，它会按你的预期工作，这可能会让你相信它确实有效那样。但事实并非如此。
TCP 很容易被想象为一根你在一端装满水的水管。添加新的一杯水并不能告诉您它的大小，只是向管道中添加更多的水。
因此，您需要在流中实现自己的“消息传递”或“打包”。
然而，情况并没有那么糟糕。Stream 是健壮的，所以如果你在数据前面加上它的长度，你就可以让它工作——只需在接收端创建某种“数据包收集机制”——有一些缓冲区可以保存部分数据包数据，直到你得到你需要的一切。
编辑：
要解决您的问题：
Flush()在这里无关紧要。Write()它会让你得到尽可能多的东西（0 是可能的） - 我认为这种行为可以改变，但它在另一端没有任何字节数n在这里，您对如何读取缓冲区有一些想法：.NET 阻塞套接字读取直到 X 字节可用？
Windows 套接字没有内部同步机制。因此，您永远无法确定您获得的字节部分是最终的，并且不需要其他数据。您将始终需要跟踪所有检索到的数据并决定何时可以停止检索。
如果流耗尽，您将获得 0 的读取大小，或者至少为 1 直到缓冲区的大小。它可以是该范围内的任何大小。常见大小是网络 MTU 的倍数（大约 1452 字节）。
您需要自己实现逻辑以逐渐将缓冲区填充到所需大小。
发送的块大小和接收的块大小之间没有联系。
文件系统基本上是唯一常见的 Stream 实现，它总是完全填满请求的缓冲区，除了文件末尾。其他 Stream 实现不保证。
这一切都是为了性能而做出的设计选择。