一个差点让产线停摆的夜班三年前做一个无线数据采集项目，设备端要往网关上报一批特征数据，本地缓存里存了大概两万条记录，每条记录里有一个变长字段，短的时候几十字节，长的时候能到十几KB。上线测试一切正常，因为测试数据只造了几百条，特征值都很短。正式跑起来第一天晚上，网关侧开始出现零星丢包，重启链路后能撑一阵，过一会儿又不行。更诡异的是，设备端日志显示“发送成功”，但网关侧根本没收到完整数据。当时以为是射频干扰，折腾了一整夜换信道、调功率、加屏蔽，问题照旧。后来抓空口日志才发现，每次出问题的都是那些特征值超过某个长度的记录。短记录一条一条过得好好的，长记录一上来，链路就像被什么东西卡住了。最后定位到：协议栈在传输超过单次承载上限的特征值时，分片协商过程出了问题。设备端以为协商好了，网关端还在等一个永远不会完整到达的分片。这个坑让我意识到，长特征值的分片传输绝不是“大了就切”这么简单，协商过程中的状态机、超时、窗口、重传策略，每一个环节都可能埋雷。下面把这段经历拆开，讲清楚里面的门道。分片协商到底在协商什么很多人一听到“分片”，第一反应是IP层那种无状态切片，每个分片独立路由，到了终点再拼。但特征值分片传输不是这个模型。它更像一次带状态的握手：发送方要先告诉接收方“我有个大家伙要过来了，你准备一下”，接收方回复“我准备好了，你按这个节奏发”，然后双方按约定好的分片大小、窗口、超时参数开始搬运。协商的核心参数通常包括这几项：单分片最大载荷：不是链路MTU，而是应用层协议栈允许的单个分片数据区长度。分片窗口：发送方在收到确认前最多能连续发多少个分片。/