【网络通信】断线重连与状态同步：把掉线做成无感体验

完整课程入口：996 全套课程体系 ｜ Lua 学习路径 ｜ 幂尔框架 mirs.cn

掉线不可避免，重复登录才是问题

无线网络下掉线是常态：切后台、电梯、基站切换。设计目标不是"不掉线"，而是掉线后自动恢复到原会话，玩家无感或接近无感。最差的做法是把断线当登出处理——玩家回来要重登、重选角、界面全重置，掉一次线流失一批玩家。

重连四步握手

断线检测先行：心跳超时（约两倍心跳周期）判定掉线，进入自动重连循环，间隔从 1 秒起步指数退避（1s、2s、4s，封顶 15s），连续 5 次失败才提示玩家手动操作。

重连成功建立 TCP 后，不要直接回到游戏，按四步走：第一步，客户端发送重连请求，携带登录时下发的会话 token 与角色 id；第二步，服务器校验 token 有效性与角色在线状态，有效则复用原会话上下文（原登录信息、临时状态、订阅的广播通道全部保留），无效则拒绝并走全新登录；第三步，客户端上报本地已确认的消息序号，服务器据此补发"断线期间"的增量变更；第四步，服务器下发全量关键状态快照（血量、位置、任务进度），客户端以快照为准重刷界面——序号增量保证不丢事件，快照保证最终一致，两者缺一不可。

状态同步的两种流派

状态同步：服务器维护权威状态，定时或变更时下发最新值，客户端只渲染不推算。实现简单、防作弊好，包量随实体数增长。帧同步：服务器只广播玩家输入，各端自己推算，包量极小、回放方便，但对确定性要求苛刻（浮点数、随机数、遍历顺序都必须一致），Lua 环境里做跨平台确定性要格外小心。传奇类即时制业务多数选状态同步 + 关键事件即时推送的混合方案。

缓冲与幂等

补发的增量消息可能乱序、重复，客户端处理入口要有序号去重与按序排队缓冲。服务器侧所有"掉线期间生效"的操作（时间到点的活动奖励）记入离线队列，重连时按序补放；领取类操作全部幂等（业务单号去重），重连导致的重复请求不会重复发货。

最后一条体验细节：重连过程中界面给明确的"重连中"状态与进度，失败后提供手动重试按钮。技术上无感很难做到十成，但"看得见的恢复过程"能消掉大半负面情绪。

掉线与登录

playoffline(actor)

人物大退触发，断线判定的落点，重连窗口从这里开始计时

playreconnection(actor)

人物小退触发，短时重连走小退，状态需要保留而不是重建

logincheckent(userID)

检测登陆信息[反外挂]，重连时的登录校验不能比首次登录弱

kick(actor)

人物强制掉线(踢人下线)，同一账号重复登录时按策略踢掉旧连接

消息收发

handlerequest(actor, msgid, param1, param2, param3, sMsg)

监听消息，重连后补发队列的入口

sendluamsg(actor, msgid, param1, param2, param3, sMsg, sendScope, targetMapId)

发送消息，状态同步的核心出口

跨服连接

checkkuafuconnect()

检查跨服连接是否正常连接，跨服场景下掉线先判链路，再判业务

checkkuafuserver()

检测当前服务器是否为跨服服务器，重连逻辑要按所在服分开处理

离线托管

offlineplay(actor, time)

离线挂机，超时未回来的连接转离线托管，避免状态直接丢失