buf = b''
while len(buf) < 4:
buf += sock.recv(4 - len(buf))
n = struct.unpack('>I', buf)[0]
收包时长度头只收到一半，struct.unpack 解出 81920，随后一直等不到这么多字节，连接卡死 30 秒后超时。先别急着动参数，把报错原文和时间点记下来，顺序反了容易白折腾。
原因不复杂，TCP 不保证一次 recv 能拿到完整头部，代码却假设前 4 字节一定齐全。长度解错之后读取条件永远不满足，缓冲区一直等下去。
「半包解析」确认了原因之后，改动尽量只碰那一处，顺手改的东西后面最容易出问题。改动写完就同步给同事，下一个人踩同一个坑，成本还是你的。
验证用真实数据走一遍，测试数据太干净，边界情况根本碰不到。能分两步做的操作就别合成一步，中间看一眼返回值，出问题好判断。
处理上按这个顺序：先循环收满 4 字节头再解析；头里的长度值做上下限校验；按长度收满 body 才交给业务；整个收包过程加一个总超时。
改完只确认一件事：改造后 20 万条消息没有一次卡死，长度超过 1MB 的异常头被直接拒绝并断开。