在开发一个多人在线聊天工具时，团队碰到了一个问题：消息偶尔会乱序、重复，甚至丢失。排查一圈网络设备和传输层设置后，发现问题其实出在应用层——报文设计没做好。
报文不是随便拼的字符串
很多人觉得，应用层协议只要把数据用 JSON 或字符串拼起来发出去就行。比如发送一条消息，直接写成：{\"user\":\"张三\",\"msg\":\"你好\"} 就完事。可现实使用中，接收方怎么知道这条消息有没有收全？如果网络抖动，数据被截断了怎么办？
这就是报文设计要解决的问题。一个靠谱的报文，不只是内容正确，还要能自描述长度、类型、版本，甚至校验机制。
结构化报文的基本要素
一个常见的做法是，在应用层报文前面加个头部（Header），说明后面数据的长度和类型。比如：
固定4字节：数据长度（uint32）
固定1字节：消息类型（如1=文本，2=图片）
可选1字节：版本号
后续N字节：实际数据（如JSON字符串）接收方先读4字节，就知道接下来要等多少数据才算是完整的一条消息。这样即使TCP粘包或分包，也能正确拆解。
举个实际场景
假设你在家用智能家居App控制灯泡。你点一下“开灯”，手机发一个请求到服务器，再转发给灯泡。如果这个请求报文没有明确的指令标识和序列号，灯泡可能误把上一条调节亮度的消息当成开灯命令，或者重复执行多次。
加上序列号和操作码后，报文就像快递包裹贴上了订单号和物品标签，谁发的、要干啥、第几次尝试，一清二楚。
别忽视编码和兼容性
早期有些系统用 ASCII 编码传文本，后来要支持中文，结果客户端不统一，有的用 UTF-8，有的用 GBK，导致乱码。所以报文设计里最好明确指定字符编码，或者干脆用二进制字段定义每个数据的类型。
另外，版本字段也很关键。系统升级后，新功能可能带新字段，老设备看不懂。有版本号就能做兼容处理，比如忽略不认识的字段，而不是直接丢弃整条消息。
简单不代表简陋
不是每个项目都要搞复杂的 Protocol Buffers 或 gRPC。很多时候，自己设计一个轻量级的应用层报文格式反而更灵活。关键是想清楚：传输的是什么？会不会被截断？如何识别完整性？未来会不会扩展？
把这些问题在设计初期理清楚，后期联调和维护能省下大量时间。毕竟，网络问题八成出在细节，而不在理论。