TcpClient高速批量发送消息时客户端偶发接收不全问题求解

你当前的TCP收发逻辑存在明显的实现错误，核心是对TCP面向流的特性理解有误，高速发包时的异常是逻辑bug导致，不是TCP本身的问题：

• 客户端使用TcpClient.Available判断是否有数据可读是完全错误的做法。TCP是无边界的字节流协议，短时间高速发送时，多条消息会被操作系统合并成单个TCP段传输，此时Available值大于0，但你仅调用1次ReadLine()就结束本轮判断，缓冲区中剩余的未读消息会一直滞留，直到下一次新数据到达才会被读取，极端情况下后续无新数据时就会永久丢失。
• 接收逻辑中遇到空字符串就直接return退出整个接收循环的逻辑存在严重缺陷：空行只是正常的消息内容，只有ReadLine()返回null时才代表连接已断开，遇到空字符串直接退出会直接终止整个接收流程，后续所有消息都无法收到。
• 发送端逐行调用Flush()会产生大量小包，触发Nagle算法导致发送效率降低，进一步加重高速发包时的粘包概率。

1. 重构客户端接收逻辑 #

不要用Available做数据到达判断，直接在独立后台线程中循环调用ReadLine()即可。ReadLine()本身是阻塞方法，无数据时会自动挂起线程不占用CPU，有数据时会自动按行依次读完缓冲区所有内容，天然解决粘包拆包问题：

public TcpClient client;
public StreamReader reader;
public ConcurrentQueue<string> commands = new ConcurrentQueue<string>(); // 用线程安全队列替代普通队列，避免多线程竞争

// 初始化连接后调用该方法启动接收
public void StartReceive()
{
    Thread receiveThread = new Thread(ReceiveProcess)
    {
        IsBackground = true
    };
    receiveThread.Start();
}

private void ReceiveProcess()
{
    try
    {
        while (client != null && client.Connected)
        {
            string message = reader.ReadLine();
            // 仅当读到null时表示连接断开，退出接收循环
            if (message == null)
            {
                break;
            }
            // 空消息直接跳过，不终止接收
            if (string.IsNullOrEmpty(message))
            {
                continue;
            }
            Debug.Log(message);
            commands.Enqueue(message);
        }
    }
    catch (Exception ex)
    {
        // 按需添加连接异常的日志、重连逻辑
        Debug.Log($"连接异常: {ex.Message}");
    }
    finally
    {
        // 清理资源
        client?.Close();
        reader?.Dispose();
    }
}

注意：如果你是在Unity等单线程模型的引擎中使用，接收线程不要直接操作引擎对象，仅把消息存入线程安全队列，由主线程轮询队列处理消息即可。

2. 优化发送端逻辑 #

批量发送消息时不需要逐行Flush，写完所有内容后一次性刷新缓冲区即可，大幅降低小包数量，提升发送效率：

public StreamWriter writer;

public void WriteListToClient(List<string> messages)
{
    foreach (var message in messages)
    {
        writer.WriteLine(message);
    }
    // 所有消息写完后统一刷新缓冲区
    writer.Flush();
}

• 只要你使用WriteLine按行写入、ReadLine按行读取，不需要自己实现额外的粘包拆包逻辑，StreamReader/StreamWriter已经帮你处理了字节流的行边界解析。
• 永远不要在TCP通信中用Available判断是否有完整消息可读，这个属性仅能表示当前缓冲区有多少字节到达，无法判断这些字节是否构成一条完整的业务消息。

内容的提问来源于stack exchange，提问作者shefasf