副本服务器如何处理玩家中途掉线

副本中途掉线是玩家非常敏感的问题。一次普通网络抖动，如果回来后发现门票没了、奖励没了、队友散了，玩家不会关心是运营商切基站还是客户端后台被系统冻结，他只会觉得服务器没有保护他的进度。副本服务器要把掉线当成日常情况，而不是罕见异常。移动网络、切后台、设备发热、家庭 Wi-Fi 漫游，都会让连接短暂中断。

处理掉线前，先区分副本类型。单人剧情副本可以暂停或保存进度；多人合作副本要考虑队友是否等待；竞技副本要防止玩家在失败前故意断线逃避惩罚；长线 Roguelike 或爬塔玩法则可能需要完整保存关卡状态。不同玩法对公平性和恢复成本的要求不同，服务端不能用同一套规则处理所有副本。

最基础的方案是断线保留窗口。玩家连接断开后，副本服务器不立即销毁角色，而是把玩家状态改成 disconnected 或 reconnect_pending。这个状态下角色如何表现，由玩法决定：可以站在原地、进入无敌保护、由 AI 托管、保持防御姿态，或者在竞技玩法里继续暴露风险。关键是状态要明确，不能让业务服务只看到一个简单的 offline。

保留窗口需要配置化。普通合作副本可以给 60 到 180 秒，给玩家重新连接的机会；实时竞技可能只能给 15 到 30 秒，否则会拖累对局；单人副本甚至可以保存到玩家下次登录。窗口太短会误伤弱网玩家，太长会让队友等待或被滥用。最好按副本类型、难度、是否消耗门票、是否有排名奖励单独配置。

重连流程要返回完整上下文。客户端重新连上后，不能只是登录成功，还要知道自己是否仍在副本里。服务器应该返回副本 ID、房间 ID、当前阶段、剩余时间、玩家位置、队友状态、怪物关键状态、掉落归属、当前逻辑 tick。客户端根据这些数据重新进入场景，而不是让玩家从大厅再走一遍匹配。否则重连成功也可能体验断裂。

多人副本还要处理队友体验。一个玩家掉线后，其他人是否能继续？队长掉线是否转移队长？掉线玩家是否可以被投票踢出？能否补人？如果副本奖励和队伍完整性相关，这些规则都要写进服务端状态机。不要把决定权全部交给客户端 UI，否则不同客户端版本可能表现不一致。

奖励规则必须提前确定。玩家掉线时队友通关，他是否有奖励？如果他已经贡献了伤害但没在结算时在线，奖励是否通过邮件补发？如果他主动退出，是否扣次数？如果是网络断开，是否和主动退出区分？这些规则看似策划问题，但服务端必须能根据事件记录做判断。没有数据支撑，规则就无法执行。

为了区分网络掉线和主动逃避，服务器要记录关键上下文。断线时副本进度、玩家血量、队伍状态、Boss 血量、是否处于结算前、客户端是否发送主动退出、最近几秒输入情况，都可以作为判断依据。竞技玩法里，故意断线逃避失败很常见，服务端不能只看连接断开就免除惩罚。

副本状态保存要有轻重之分。短局副本可以只保存关键状态，掉线窗口结束后直接结算或销毁。长线副本需要周期性快照，包含随机种子、关卡阶段、怪物状态、玩家资源和已触发事件。不要把表现层状态全部保存，比如粒子、动画帧、临时 UI 提示，这些重连后可以重建。保存越精确，成本越高，要根据玩法价值选择。

托管逻辑要谨慎。很多游戏会在玩家掉线后让 AI 接管角色，但 AI 太强会被玩家利用，太弱又会让队友不满。托管可以只做最低限度动作，比如跟随队伍、躲避明显危险、保持防御，不主动释放高价值技能。竞技游戏中，托管还可能影响公平性，甚至不如直接保持原地并按规则判定。

房间服务和网关之间要有明确协议。网关发现连接断开，通知房间服；玩家重连到新网关，新网关要向房间服声明 session 恢复；房间服确认后重新绑定玩家连接。这个过程中要防止旧连接和新连接同时存在。可以使用 session_version，每次重连递增，房间服只接受最新版本的输入。

客户端也需要知道自己处于恢复流程。重连时最好展示“正在恢复副本”，而不是普通登录加载。如果恢复失败，服务器要给明确原因：副本已结束、保留时间已过、玩家被队伍移除、版本不兼容。明确原因可以减少客服压力，也能让玩家理解规则。

副本掉线还要配合日志。每次进入、断开、重连、超时移除、结算、奖励发放都应记录同一个 trace_id 或 dungeon_run_id。玩家反馈时，开发能看到他断线发生在第几阶段，是否重连成功，奖励为何发或不发。没有日志，掉线问题会变成最难查的一类线上投诉。

最终，副本服务器要保证的是中断可恢复、规则可解释、资产不丢失、队友不被无谓拖累。掉线不是一个网络模块的小异常，而是副本状态机的一部分。把它设计清楚，玩家在弱网环境下也会觉得游戏可靠得多。

副本状态机要能表达掉线

很多掉线问题难处理，是因为房间状态机只有 playing、finished、closed 几个状态，玩家状态也只有 online 和 offline。真实副本里，玩家可能在线但切后台，连接断了但仍在保留窗口，已经重连但客户端还在加载场景，被队伍移除但奖励待结算。状态表达不出来，业务逻辑只能堆条件。

可以把玩家在副本内的状态拆得更细：active 表示正常参与，network_unstable 表示心跳异常但尚未断定，disconnected 表示连接断开且处于保留窗口，reconnecting 表示新连接已建立但状态尚未同步完成，removed 表示超过窗口或被规则移除，settled 表示奖励已处理。每次状态变化都记录时间和原因。这样副本逻辑、奖励逻辑和客户端展示都有依据。

房间本身也可以有 draining 状态。维护前或房间服准备迁移时，不再允许新玩家进入，但允许当前玩家完成或保存进度。这个状态和玩家掉线配合，可以避免维护时把大量副本强行中断。

重连同步应该包含哪些数据

重连不是简单地把玩家传回地图。客户端需要恢复足够多的上下文，才能继续表现得自然。最少需要副本基础信息、玩家自身状态、队友状态、关键怪物状态、当前阶段、剩余时间、可交互对象、已获得但未结算的掉落、服务器逻辑帧或时间戳。对于动作玩法，还需要最近状态快照和若干帧输入或事件，方便客户端平滑追上。

同步数据不能无限大。服务器应该区分权威状态和表现状态。血量、位置、技能冷却、Boss 阶段、机关开关是权威状态；粒子效果、飘字、镜头震动、临时音效是表现状态。重连时只恢复权威状态，表现由客户端重新播放或忽略。这样既减小同步包，也避免恢复出奇怪的过期表现。

如果副本逻辑基于 tick，重连响应里要带当前 tick 和客户端应从哪个 tick 开始接收增量。客户端先应用快照，再处理后续增量事件。如果没有 tick，客户端很难判断哪些事件已经过期，哪些还需要播放。

掉线期间的角色处理

掉线角色如何处理，会直接影响队友体验和公平性。合作副本里，掉线角色可以进入跟随托管，降低队伍损失；高难副本里，托管过强可能被利用；竞技副本里，托管可能改变对局结果。服务端最好给每类玩法配置掉线行为，而不是统一 AI 接管。

一种折中做法是分阶段处理。刚断线的前几秒保持角色原状态，避免瞬间变化；超过短窗口后进入保守托管，只做基础移动和防御；超过长窗口后移除或判定失败。这样既给短暂抖动留空间，也不让队友无限等待。托管期间的输入应由服务器生成，并在日志里标记来源，避免和玩家真实输入混淆。

如果掉线玩家持有关键任务物品或队长权限，服务端要有转移规则。比如队长掉线超过 30 秒自动转给队伍中在线时间最长的人；关键机关道具可以掉落到场景或转移给队友；投票操作在掉线后自动弃权。这些规则不提前设计，副本会卡在各种边界状态。

结算和补偿的可信规则

副本奖励通常和参与度有关。服务端可以记录玩家在副本中的在线时长、有效输入、伤害、治疗、承伤、任务贡献、是否在结算时处于保留窗口。奖励规则可以基于这些数据判断。比如玩家贡献足够且只是结算前短暂掉线，可以通过邮件发奖励；玩家开局后立刻掉线且未贡献，则不发或只返还门票。

门票和次数消耗也要明确。进入副本时扣，还是结算时扣？如果进入时扣，副本创建失败或服务器异常要返还；如果结算时扣，玩家可能中途退出规避消耗。不同玩法选择不同，但要有故障补偿路径。所有扣减和返还都要有流水，避免重复返还。

玩家主动退出和网络断开要区分。主动退出通常来自客户端明确操作，网络断开来自连接层事件。虽然恶意玩家也可能直接断网伪装网络问题，但服务端至少要记录两类来源。竞技玩法可以把两者都视为失败，合作玩法则可以对网络断开更宽容。

服务迁移和房间恢复

房间服本身也可能故障。如果房间服崩溃，玩家重连时不只是恢复连接，而是要恢复整个副本。对高价值副本，可以定期保存快照和关键事件。新房间服读取快照后重建状态，再允许玩家重连。对低价值短副本，可以直接判定副本异常结束并返还消耗。恢复成本要和玩法价值匹配。

副本服务器处理掉线的成熟度，最终体现在玩家是否觉得规则公平。弱网玩家希望能回来，队友希望不被拖累，竞技玩家希望没人靠断线逃罚。服务端要在这三者之间做清晰取舍，并用状态、日志和奖励规则把取舍落地。

上线前的工程核对

真正把这套方案放进生产环境前，团队还需要做一次朴素但有效的核对。第一，确认关键状态都有唯一标识，能从日志里串起一次完整链路。第二，确认重复请求不会造成重复副作用，尤其是资产、奖励、排名、邮件这类玩家能直接感知的结果。第三，确认配置、开关和版本都能回滚，而不是只能向前发布。第四，确认客服或运营能查到必要证据，避免所有问题都只能找开发临时查库。

还要准备一组小规模演练。演练不需要复杂，但要覆盖真实失败：服务重启一次，消息重复投递一次，下游接口超时一次，客户端重连一次，配置回滚一次。很多设计在文档里看起来可靠，只有演练时才会暴露状态缺失、错误码不清、日志字段不够、后台按钮不可用这些具体问题。把这些问题提前暴露出来，比在线上由玩家帮你测试要便宜得多。

最后，要把边界写进团队共识。哪些数据必须强一致，哪些可以最终一致；哪些操作允许重试，哪些必须人工确认；哪些异常直接降级，哪些必须停止入口。游戏服务器开发最怕每个模块都各自理解规则。规则统一后，代码实现、运营处理和客服解释才会站在同一条线上。