【网络通信】断线重连去重：消息序号防止奖励重复弹窗

弱网环境下断线重连是家常便饭，但重连后服务端补发的消息可能跟断线前的尾部几条重复：奖励弹窗弹两次、邮件红点闪个不停。本文在996引擎前端用消息序号做去重过滤。

场景与痛点

玩家在通勤路上玩游戏，网络抖动断线三秒后自动重连。服务端的下行消息有补发机制，断线窗口内的消息会重发一遍，客户端如果不加处理，同一条获奖通知就会触发两次弹窗与音效。更麻烦的是请求类消息也可能因重试被发出两次，服务端扣两次道具。

实现思路

服务端给每条下行消息带自增序号，客户端记录已处理的最大序号，小于等于它的直接丢弃。上行方向客户端给请求也带序号，服务端对写操作请求做幂等校验，同一序号只执行一次。

关键实现

local lastSeq = 0
SL:RegisterLuaNetMsg(7001, function(data)
    local seq = tonumber(data.seq) or 0
    if seq <= lastSeq then return end
    lastSeq = seq
    handleAward(data)
end)

上行请求同样封装序号，等待服务端回执后才算完成：

local reqSeq = 0
local pending = {}
local function sendReq(cmd, body)
    reqSeq = reqSeq + 1
    pending[reqSeq] = true
    SL:SendNetMsg(cmd, { seq = reqSeq, body = body })
end

服务端对写操作按序号判重，重复请求只回执不执行，客户端收到回执后清掉pending记录。

细节与避坑

lastSeq不要存在UI层变量里，重连重建界面后会归零，必须挂在持久会话对象上。序号接近溢出前要约定重置协议，服务端发重置消息后双方同步归零，窗口期内暂时改用内容摘要判重。展示类消息允许丢弃，写类消息必须幂等，两类协议分开设计。重连成功后先拉一次全量状态再开增量通道，避免序号断档造成丢消息。

小结

序号去重是断线重连的标配伴生机制，客户端丢弃重复下行，服务端幂等上行，两半拼在一起才完整。只做客户端去重的方案，挡不住请求重放。

延伸思考

把序号机制下沉到网络库封装层，业务代码无感知，是长期最省心的做法。多人副本场景还要考虑广播消息与私发消息共用序号空间还是分开，建议分开，互不干扰。