前两年做一个分布式采集系统的联调，我们这边用一套自研的通信中间件，对端是一家合作方提供的协议栈实现。两边单独跑各自的单元测试全绿，抓包看报文格式也完全符合接口文档。但一连起来就出问题：链路建立后，每隔十几秒必然断一次，重连后又正常，循环往复。

当时第一反应是网络抖动，换了交换机、加了屏蔽线、甚至把两台设备搬到同一个机柜里，故障依旧。后来花了两天时间才定位到根因——对端在收到我们发送的某种确认帧后，会立刻回一个复位帧，而我们的协议栈认为这个复位帧是非法状态转换，主动断开连接。但对端坚持说他们的行为符合规范，因为规范里写的是“可以”回复位，不是“必须”回。

这个坑让我彻底明白一件事：互操作测试中最耗时的，从来不是协议本身不通，而是两边都认为自己“对”，但“对”的方式不一样。

先看现象：区分“不通”和“通而不稳”

互操作问题大致分两类。一类是压根连不上，握手阶段就失败，这种反而好查，抓包对比字段就能定位。另一类是能通，但通得不稳定——周期性断开、偶发超时、大数据量时丢帧、特定命令无响应。第二类才是真正的泥潭。

我后来养成一个习惯：遇到互操作问题，先花十分钟做现象分类，而不是直接扑上去抓包。分类的依据很简单：

• 故障是否与时间相关？比如固定间隔出现，那大概率是某个定时器超时或保活机制不匹配。
• 故障是否与数据量相关？小包正常，大包出问题，那可能是分片重组或流控窗口差异。
• 故障是否与特定交互序列相关？比如只在查询命令后出现，那可能是状态机迁移条件不一致。
• 故障是否与并发相关？单条命令正常，并发多条就乱，那可能是事务ID分配或重传机制冲突。

这个分类过程