我很确定，虽然记忆是在时间的迷雾深处，我见过它返回零之前，在大量数据传输的情况下，另一端没有跟上。
在这种情况下，远程TCP堆栈缓冲区已从存储器填满，堆栈已通知本地端它将延迟，直到一些空间被清除，并且本地缓冲区也已填满。
此时，从技术上讲，这不是一个错误（因此没有返回-1），但本地堆栈无法接受任何数据。
我不完全确定现在的情况是这样的，因为目前的Posix标准似乎表明它在这种情况下会简单地阻塞（或者失败，如果它设置为非阻塞）。
然而，我怀疑这是一个没有实际意义的观点。你 * 确实 * 有可能返回 * 少于 * 你请求发送的字节，因此你应该有代码来处理这个问题。
而且，由于处理“比您请求的少一个字节”和处理“零字节”的逻辑几乎相同，所以您也可以假设它可以返回零。

当然，总是存在这样的情况：您传入零作为要发送的字节数...在这种情况下，“返回发送的字节数”将指示它应该返回零字节。
最好还是正确处理返回零的情况;不会有坏处，而且可能会有帮助。

对此问题的答案很可能取决于具体实现，因此会因操作系统而异。
在一种情况下，当您请求传输0字节时，预期会出现0。

BSD man 页指出：
如果套接字上没有可用的消息空间来保存要传输的消息，则send（）通常会阻塞，除非套接字已被置于非阻塞I/O模式。
Posix规范更进一步，指出在阻塞模式下，除非发生中断，否则 * 所有 * 数据都会被传输。
在这两种情况下，除非提供的计数为零，否则无法返回零。

我现在确实观察到AF_UNIX类型套接字上的send(2)返回零。
是的，这是由于size场的零值。
那么，JFYI。

send(socket, buf, 0, 0)返回0
我想提供一些简单的代码供其他人测试。

服务器：

在一个终端中：
nc -l localhost 10086

客户：

在另一个终端中：
第一个