串口服务器重启后指令粘在一起，怎样核对拆包边界

串口服务器的TCP侧是字节流，接收回调次数不是设备帧数。接收器应按设备协议的终止符、长度或校验规则持续累积，能处理一帧分多次到达及多帧一次到达。

适用条件与证据边界

RFC9293的字节流语义适用于TCP侧；串口侧帧规则需另查设备协议。本附件使用编辑自定义的CR结尾ASCII演示协议，不是任一厂商可直接执行的控制命令。

本文交付可执行的测试方法、合成演示和空白记录表；未连接现场硬件，未取得设备实测、现场照片或稳定性结论。规范定义与示例判据分别说明，示例数值不能用作设备参数。

按这个顺序核对

1. 先固定网关模式、串口参数及应用层帧定义，保存网关重启前后配置，排除恢复默认参数。

2. 向离线接收器依次输入完整帧、跨回调分段帧、合并帧三种字节块，比较输出是否相同。

3. 在帧尾CR单独到达以及两帧之间没有网络空闲时测试，确认不会用“这次读取结束”充当帧结束。

4. 加入超长无终止符、断线遗留半帧和重连新帧，定义清理与告警策略；连接重建后不能把旧残片拼到新命令。

输入与期望结果（合成演示）

接收块	按CR拆帧的期望	剩余缓冲
STATE=O + N\r	STATE=ON	空
A=1\rB=2\r	A=1；B=2	空
TEMP=2	无完整帧	TEMP=2

附件三组输入经本地累积解析器运行，输出应分别为一帧、两帧、零帧加残片。它只验证演示CR协议，不能直接拿CR规则拆Modbus RTU。

下载夹具并复用

下载本题JSON夹具与空白工作表。文件中的“演示输入”用于先核对判断逻辑，“现场空白记录”供复制后填写；原演示数据请保留，实测数据另存一份并标注型号、版本和采集时间。可先用 python -m json.tool fixture.json 检查结构，再按上表逐行核对输入与预期。

验证网关重启问题时，要同时保存网络接收块与串口发送记录。若TCP侧已经完整、串口侧出现截断，问题在另一层；若接收器在不同分段下输出不同帧，先修应用拆包。不要仅靠延长网关打包时间把两条命令凑成一块，这会让正常网络波动再次暴露问题。 超时重置的缓冲应关联会话编号，并保存被丢弃字节，便于解释为何某条回复未被接收。清缓冲是恢复策略，不能把它作为原始数据从未到达的证据。

容易误判的边界

Modbus RTU还涉及时间间隔与CRC，TCP封装Modbus则用MBAP长度；二者不能混用。网关“打包超时”影响传送时机，但不应成为上层唯一帧判据。

继续核对

基础说明见串口服务器（串口转网口）选型科普；还可核对串口回包偶尔少一截，怎样区分接收超时和实际丢字节。相关资料可从串口与 Modbus 对接专题继续查找；需要核对项目实现时，按SoftControl 设备联动需求列出具体接口与验收条件。

一级依据

• RFC 9293 §2.2：字节流没有应用消息边界

核对日期：2026-10-23。引用版本用于界定本文方法，实际设备支持范围仍须与对应型号手册核对。