自研Python大富翁游戏本地通信正常，公网传输时Pickle反序列化报错

所有报错的核心诱因是没有正确处理TCP面向字节流的分包、粘包特性，本地回环环境因为链路延迟极低、缓冲区排队少，问题不容易暴露，跨公网传输时受MTU限制、拥塞控制、网络延迟波动的影响，字节流错位的概率会陡增，具体对应代码里的问题点：

• 现有代码所有recv()调用都默认单次调用能拿到完整长度的目标数据：不管是读取2字节的帧长度、读取Pickle序列化的帧头、读取消息正文，单次recv()的返回值长度都可能小于预期。公网环境下TCP完全可能把一帧数据拆成多个包传输，这时候读出来的是半截数据，字节偏移错位后喂给Pickle，就会触发invalid load key报错——比如报错里的读取到空格，本质就是粘包时把上一条文本消息里的空格字符，当成了当前帧的Pickle数据开头。之前测试加50ms发送间隔能提升稳定性，只是给TCP缓冲区留了排空的时间，降低了粘包概率，没有从根本上解决拆包的问题，运行久了必然再次触发。
• 序列化逻辑存在笔误：服务端recv方法中，当消息类型是obj时，已经从连接里读取到了Pickle序列化的原始字节，反而又执行了data = pickle.dumps(data)，相当于对字节流做了二次序列化，客户端拿到的数据和约定格式完全不匹配，进一步放大了跨网传输的错位问题。
• 没有处理连接断开的边界场景：当连接因为网络波动半断开时，recv()会返回空值，现有代码没有对返回值做非空判断，直接把空值转成整数、喂给Pickle反序列化，就会导致服务端卡在接收逻辑里，后续所有收发流程全部错位。
• 批量发送逻辑会加剧粘包：服务端循环单条发40条短文本，每个短消息独立成TCP帧，大量小包在公网传输时容易被网络节点合并成大的字节块，接收端如果没有严格的帧解析逻辑，必然会把多帧数据揉在一起解析。

• 封装全量读取的通用方法，替换所有零散的recv()调用，强制保证每次读够指定长度的字节，解决TCP拆包问题：

def recv_all(conn, target_length):
    buffer = b""
    while len(buffer) < target_length:
        chunk = conn.recv(target_length - len(buffer))
        if not chunk:
            raise ConnectionError("网络连接中断")
        buffer += chunk
    return buffer

把原有代码里所有`conn.recv(2)`、`conn.recv(header_size)`、`conn.recv(header["message_length"])`的逻辑，全部替换成调用`recv_all()`获取对应长度的数据，从根源上避免因为单次读取长度不足导致的字节错位。

• 修正obj类型的序列化逻辑错误：删除服务端recv方法里对obj类型的二次pickle.dumps()调用，收到的原始字节流直接作为对象数据返回，保持和客户端约定的序列化格式一致。
• 优化批量推送的发送逻辑：把原本循环发送40条独立短文本的逻辑，调整为在服务端先把所有要推送的文本拼接成单条长消息，一次性发送给客户端，减少TCP帧的数量，从源头降低公网传输的粘包概率。
• 增加帧格式的校验逻辑：可以在Pickle序列化的自定义帧头里增加固定的校验魔数（比如固定前2个字节为b"MP"），接收端解析每帧数据时先校验魔数是否匹配，如果不匹配说明已经出现字节错位，直接清空接收缓冲区重置状态，避免错位状态持续触发连续报错。

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