接收端统计每分钟应到 6000 个包，实际 5880 个，序列号在 4471、4475、4482 处断开，业务侧出现 2% 的数据缺口。碰到这种情况，我一般先确认改动有没有真的生效。
原因不复杂，UDP 不保证送达也不重传，缓冲区满、链路拥塞都会直接丢。协议本身没有序列号和确认，缺了只能靠应用层自己发现并补。
「UDP 丢包补偿」这类改动最怕改一半，回滚脚本先准备好，再动生产。别只看报错的最后一行，往上看几行，真正的起因通常在上面。
if seq != expect:
missing.add(expect)
expect = seq + 1
同类问题如果隔一段时间又出现，多半是某个定时任务或重启流程把改动冲掉了。把这次用到的命令存进笔记，比记住结论有用，换个环境还能照着走。
改完隔一天再看一次，当场正常不代表能稳住。
具体做法是，报文头加单调递增序列号；接收端记录空洞区间；定时发 NACK 请求补发；发送端缓存最近 2 秒的报文。
最后用这个标准收尾，加上应用层补发后缺口从 2% 降到 0.05%，每分钟补发 6 个包，业务校验全部通过。