最新盐场bug反馈 2026.5.17 ¶

问题1：
状态：已修复，验收通过
现象：盐场一个战场有几十家俱乐部 一个大本营多家俱乐部共同占用 复活后随机出现在一个地方
预期:盐场每场比赛每个战场内最多20 家俱乐部参加 20个大本营 只会在自己家大本营复活
截图：

问题2：
状态：已修复，验收通过
现象：使用复活丹复活显示繁忙 无法复活
预期：使用复活丹后可以正常复活
截图：
修复依据：截图中的“操作太频繁，请稍等片刻”来自客户端 LegionWarModule._readySendMsg 的本地频控，不是服务端错误文案；客户端发 WarService.resurrect 后只监听 War_ResurrectNotify 来清除 Resurrect 频控缓存和刷新复活状态，并不监听 War_ResurrectResp。生产一区 2026-05-25 15:04 以后日志能看到多个角色短时间重复 war_resurrect，例如 995169 在 15:10:35、15:10:54、15:11:12、15:11:21 连续请求，符合客户端未收到/未应用复活完成通知后重复点击的表现；旧日志没有记录 war_resurrectnotify 的发送结果，无法直接证明是否丢包。服务端旧手动复活链路先发 war_resurrectresp，再把本人 war_resurrectnotify 当普通 notify 发送，普通 notify 属于低优先级队列，队列满可丢弃；而客户端清频控依赖这个 notify，所以高压时会停留在“复活中/频控”状态。已修复为手动复活本人 war_resurrectnotify 使用 sendCriticalNotify 走高优先级队列，且不再重复低优先级发送；新增 [bug2] manual_resurrect_send 日志记录 roleID、battlefieldId、seq、respSent、notifyCriticalSent、state、position、leftFreeReviveTimes、ballItemId、ballLeft、hasTeam、teamLeaderID，后续可用日志直接闭环验证。

问题3：
状态：已修复，验收通过
现象：点击组队可以看到和邀请别的俱乐部的人
预期：组队人员列表内只显示本俱乐部空闲的人
截图：

问题4：
状态：已修复，验收通过
现象：盐场内免费复活无上限 且免费复活倒计时结束后直接进入战场
预期：每场战斗每位玩家有 5 次复活机会，武将全部阵亡后，等待 1 分钟即可复活；复活后需要玩家重新布阵，此时可以更换参赛阵容，且精力值重置为 100；复活次数耗尽后玩家将进入观战状态
使用复活丹道具可以直接复活，不消耗复活次数；复活次数用尽后也可以使用复活丹；玩家俱乐部被淘汰后，无法使用复活丹复活
截图：
修复记录：截图里同时出现免费复活倒计时和复活丹入口，客户端 MapScene._diedUpdate 在 self.state 不是 resurrect 且倒计时归零时会走 _revive()，LegionWarPlayer.svrState 只有收到服务端 state=over && allowRevive=true 才会进入复活丹页。生产一区 2026-05-25 15:03 后存在大量 war_suicide/war_resurrect，旧日志只能看到请求，缺少自动复活到点后的状态和通知细节。服务端根因是 scheduleAutoRevive 免费次数耗尽分支只临时修改 notify 的 allowRevive，没有把快照权威状态从 die 倒计时态改成 over + allowRevive，且写锁内调用 applySelfFields 会重入读锁导致该分支通知可能发不出去。已改为先落库/快照 revive=5, reviveTimes=0, reviveTime=0, state=over, allowRevive=true, type=player，再用 applySelfFieldsLocked 构建通知，并增加 [bug4] scheduleAutoRevive free_exhausted_to_item 日志记录旧状态、新状态、免费次数和 guest 清理结果。验证：GOCACHE=/tmp/go-build go test . -run 'TestScheduleAutoRevive_FreeRevivesExhaustedStaysOnItemRevive|TestScheduleAutoRevive_KeepsReviveScreenStateAndTeam|TestScheduleAutoRevive_StaleMarchStateForcedBackToWatching|TestScheduleAutoRevive_SkipsStaleTimerFromPreviousDeath' 通过。

问题5：
状态：已修复，验收通过
现象：玩家佩戴四圣飞艇后盐场内行军不显示飞艇
预期：正常显示自己和他人佩戴的行军飞艇
截图：

补充修复记录：生产一区角色样本显示顶层 airshipId=0，但真实穿戴记录在 dress["3"].used。服务端盐场入场/恢复旧逻辑只读取顶层 role.AirshipId，导致下发 roles[*].airshipId=0，客户端 LegionWarPlayer 按该字段取 AirshipConf 时自然显示默认/无飞艇。已改为盐场角色资料补齐时优先使用顶层 airshipId，顶层为 0 时从 dress["3"].used 兜底，并让 ResolveEnterRoleProfile 在主缓存缺少飞艇时继续从 fallback 补字段。验证：GOCACHE=/tmp/xianyu-gocache go test . -run 'TestSaltfieldRoleAirshipID|TestSettleRelayPvPMatch|TestSanitizeBuildingMembersByPosition|TestRemoveRoleFromBuildingMembers|TestCompleteBattle_ReturnsActualRemovedBuildingDeltaForLoser|TestStartBattle_RemovesGhostTargetInsteadOfRepositioning|TestCompleteMarch_PrunesGhostDefenderAndKeepsArrivalsIdle|TestStartAttackBuilding_PrunesGhostEnemyMemberBeforeEnemyCheck' 和 GOCACHE=/tmp/xianyu-gocache go test ./domains/legion/war/saltfield 通过，待线上验收。

问题6：
状态：已修复，验收通过
现象：盐场内例 从1号地飞到2号 飞行期间 显示人还在1号地 等到了2号地 1号地才显示消失
预期：点击行军后 1会立马从一号地消失 一直到行军结束出现在2号地
截图：

修复记录：截图中行军路线已经出现，但出发建筑防守队列仍显示头像。客户端 LegionWarBuilding 的防守/攻击队列由 building.memberV2 遍历生成，LegionWarBattleField.updateServerData 对 Map 做增量合并，必须收到删除标记或权威快照中移除。生产一区 2026-05-25 15:02 后有大量 war_startmarch，如 18:52:37 roleId=22446 from=12_19 to=14_20，旧日志能看到行军创建和广播，但缺少源建筑 member/memberV2 清理结果。服务端根因是 BattlefieldSnapshot.StartMarch 只从源建筑 member 删除行军队伍，没有同步删除 memberV2；后续广播、重进或全量快照会把源建筑队列头像带回。已改为行军开始时从源建筑 member 和 memberV2 同时删除队长及全队成员，并增加 [bug6] StartMarch source_cleanup 日志记录战场、起终点、队伍成员、member/memberV2 删除数量和剩余数量。验证：GOCACHE=/tmp/go-build go test . -run 'TestStartMarch_UpdatesWholeTeamStateToMarch|TestStartMarch_NormalizesSoloSelfLeaderTeam|TestStartMarch_NormalizesSoloNoTeamRole|TestCompleteMarch_UpdatesWholeTeamArrival|TestCompleteMarch_RemovesStaleHomeMember' 通过。

问题7：
状态：已修复，验收通过
现象：切完后台回来后 显示恢复战场 恢复后点击界面无反应 必须大退游戏重新进入盐场
预期：恢复战场后 可以正常游戏
截图：

修复记录：截图显示停留在 LegionWarRestorePanel 的“正在努力恢复战场…”遮罩，界面点击被遮罩挡住。客户端后台恢复链路会请求 war_getbattlefieldinfo，并按进入战场协议形状重建战场，因此服务端恢复包必须具备 battlefield/self/battleList/roleInfo/legionInfo 等字段。生产一区 2026-05-25 15:01 后存在大量 war_getbattlefieldinfo，旧日志只有 recv/handle，缺少出包字段摘要，无法直接判断恢复包契约是否完整。服务端根因是 BuildBattlefieldInfoPayload 只从 snapshot.Data 继承顶层字段，实时快照中的战斗列表主要在 battlefield.battleList；当顶层 battleList 缺失时，恢复重建包与 War_EnterBattlefieldResp 契约不完整，可能导致恢复遮罩无法正常结束。已改为服务端恢复包强制补齐顶层 battleList（优先 battlefield.battleList，其次 battlefield.battles，否则空 map）和 roleCodeId，并增加 [bug7] war_getbattlefieldinforesp_restore_contract 日志记录 rawKeys、self、battlefield.self、battleList、roles、buildingData、roleInfo、legionInfo。验证：GOCACHE=/tmp/go-build go test ./domains/battlefield/view 和 GOCACHE=/tmp/go-build go test . -run 'TestStartMarch_UpdatesWholeTeamStateToMarch|TestScheduleAutoRevive_FreeRevivesExhaustedStaysOnItemRevive' 通过。

问题8：
状态：已修复，验收不通过
现象：盐场战报内 战报详情显示为空
预期：正常显示该次战斗的详情
截图：
、
修复依据：截图中战报列表已有双方头像、胜负和时间，但点进“战斗详情/统计详情”后输出、治疗、承伤列表为空。客户端 LPReportDetailDialog 点击详情时无条件调用 NetBattleService.getEncryptedBattleRecord(EMBattleRecordType.payload, r.ossFileName)；服务端 legion_getpayloaddetails/domains/legion/read/details.go 对盐场本服快照战报下发的是 recordIsOss=false、recordId=<battleID>、ossFileName=""，真正详情应走 LegionWarService.getBattleRecord({recordId})，并由服务端 legionwar_getbattlerecord 从 BattlefieldSnapshot.Battles 返回带 result.sponsor/accept.teamInfo 的记录。当前本地只保留 server/logs/2026-05-25/app.log，未找到可用 protocol/security 现场链路；但从截图、客户端固定 OSS 分支、服务端本服记录协议形状可以确定根因是客户端忽略 recordIsOss=false 导致拿空 ossFileName 请求战斗记录。已改为客户端按记录类型分流：OSS 记录继续走 NetBattleService，本服快照记录走 LegionWarService.getBattleRecord(recordId)，并保留异常 recordId/ossFileName 控制台日志便于后续定位。验证：node --check client/assets/game/scripts/LPReportDetailDialog.js 通过；cd server && GOCACHE=/tmp/go-build go test . -run 'TestLegionWarGetBattleRecordHandler_ReturnsSnapshotBattleInfo|TestLegionGetDetails_UsesArchivedSnapshotWhenLiveStoreIsReset' 通过。

问题9：
状态：已修复，验收通过
现象：已经布阵进入盐场后 一直弹出进场战斗页面
预期:进场后不会一直弹出进场战斗页面
截图：
修复依据：生产一区 2026-05-25 15:20 后日志显示同一玩家重复发送 war_setbattleteam/war_teamsetbattleteam/war_startmarch/war_speedup，且 war_startmarch 返回 already has an active march；服务端已修复布阵状态机，角色处于 march/combat 或存在 active march/battle 时，布阵协议不再修改快照、不再把角色重置为 idle，并返回当前战场状态用于客户端同步。

问题10：
状态：已修复，验收通过
现象：
预期：占领的地 永远不会突然消失 只会被别的俱乐部占领
截图：

修复依据：生产一区 2026-05-25 15:01 后日志显示不同玩家进入盐场时 buildingData count 在 97/99 间跳变，说明同服存在多个 battlefield；客户端收到 buildingData 增量会直接按坐标更新本地地块归属，若服务端全局广播其他 battlefield 的建筑包，就会把本战场占领地刷新成另一个战场状态。服务端已将带 battlefieldId 的战场广播按 battlefieldId 隔离，避免跨战场建筑/行军/战斗/复活增量串包。

问题11：
状态：已修复 验收通过
现象：盐场内宠物战力加成不对 外面加14亿 盐场里加2亿
预期：盐城内和外面加成一样
截图：



修复依据：测试服 2026-05-28 12:47 日志确认同一角色、同一阵容、同一宠物下，外部 pet_load 完整战力为 110059432，而旧 hero_calcpowerbyteam 只返回 29354807；旧逻辑只替换宠物自身战力，未让 petUId 临时作为装备宠物参与英雄属性/被动完整加成。服务端已废弃 powerWithSelectedPet 替换算法，hero_calcpowerbyteam 与盐场 calcPowerByBattleTeam 均改为按本次 battleTeam/lordWeaponId/petUId 构造临时角色并走完整 bonusCalculator.Calculate 公式，盐场布阵与外部战斗统一同口径；测试服已重新打包更新至 2026-05-28 12:52 二进制。

问题12：
状态：已修复，验收通过
现象：布阵里战力和进场后战力显示不一致
预期：布阵时是多少 进场后就是多少
截图：

修复依据：截图中队列详情显示 179.1亿/214.1亿，赛前布阵显示 216.6亿；客户端赛前布阵通过 hero_calcpowerbyteam 展示全量阵容战力，队列详情读取 LegionWarPlayer.power。生产一区 2026-05-25 14:00 后日志显示 war_teamsetbattleteam/war_setbattleteam 请求携带 lordWeaponId、petUId，说明服务端应以保存布阵后的全量 role.power 为准。服务端 war_getteaminfo 旧逻辑会把 teamInfo 中 5 个英雄的战力求和写回 roles[roleId].power，该求和不包含宠物/主公武器，导致正确的布阵总战力被队伍详情查询降级。已修复为：war_getteaminfo 只给英雄明细补 power，不再用英雄求和覆盖角色总战力；响应 power 优先返回战场角色已保存的全量 power，并增加 [bug12] war_getteaminfo keep role power 日志记录 rolePower 与 heroOnlyPower 差异。

问题13：
状态：已修复，验收通过
现象：玩家开启小队后死亡后还显示在原地 不会消失 显示复活中
预期：死亡后就会消失在原地
截图：

修复依据：截图显示地图建筑上仍残留小队头像，队列详情里同一批玩家状态为“复活中”。生产一区 2026-05-25 15:10 后日志有大量 war_suicide/war_resurrect，说明死亡/复活链路在高频触发；客户端 LegionWarBuilding 根据 building.memberV2 生成防守/攻击队列，即使角色 state=die，只要 memberV2 残留就会继续显示“复活中”。服务端单人死亡链路已清 member/memberV2，但组队接力结算 SettleRelayPvPMatch 旧逻辑只删除 building.member，漏删 memberV2。已修复为组队败方整队死亡时同时清理所有建筑的 member/memberV2，败方队长和队员统一 state=die、position=-1、type=guest、hasTeam=false，并在最终战斗通知中对败方整队下发 member/memberV2 删除 delta；新增 [bug13] relay_dead_cleanup 日志用于核对 loserKeys 与 buildingDeltaKeys。
补充修复记录：复查生产 2026-05-25 归档快照发现 memberV2 中存在大量 die/watching/position=-1_-1 的非法成员，说明仅清理败方 memberV2 不足以阻断后续写回。已补统一建筑成员不变量：只有 roles[*].state in (idle, combat) 且 roles[*].position == buildingId 且非 guest 的角色允许保留/写入 building.member/memberV2。CompleteBattle、SettleRelayPvPMatch、CompleteMarch、StartBattle、StartAttackBuilding、RejoinMemberToLeaderHome 均已按该不变量收紧，并增加 [bug16] 定位日志。验证新增集成测试覆盖组队死亡不再把非法成员重新置 idle、开战点幽灵目标不改坐标、行军到达不误判幽灵守军、攻打建筑前先剔除幽灵敌方成员。

问题15：
状态：已修复，验收通过
备注：退出盐场再进会消失 过一会又会 突然出现
现象：俱乐部大本营被占领后俱乐部玩家还存在在地图上
预期：大本营被占领后 这个俱乐部所有玩家都会从地图消失
截图：

修复依据：截图显示大本营/据点被攻打后，地图和队列详情仍能看到该俱乐部玩家“驻扎中”。生产一区 2026-05-25 15:02 后日志有大量 war_startattackbuilding 进入攻打建筑链路，但旧日志没有淘汰清场明细；客户端 LegionWarBuilding.setServerData 会遍历 building.memberV2、battleQueue、marches 生成地图头像和队列详情，LegionWarBattleField.updateServerData 对 Map 增量是合并语义，缺字段不会删除旧队列。服务端 OccupyBuildingLocked 已能识别“大本营被占领”并调用 eliminateLegionLocked，但旧淘汰逻辑只把成员置 watching/清部分建筑 member，漏清 memberV2、teamMap/teamIds、全局 marches、building.battleQueue/marches 和未完成 Battles，且通知未携带这些删除 delta，导致客户端保留旧玩家。已修复为大本营被占领时服务端根治淘汰清场：被淘汰军团角色统一 state=over、allowRevive=false、position=-1、hasTeam=false；清理 teamMap/teamIds、marches、Battles、所有建筑 member/memberV2/battleQueue/marches，并对客户端下发显式 nil tombstone；同时 IsRoleEliminated 改为按军团状态/大本营归属判定，后续攻打、行军等请求会被拒绝。新增 [bug15] home_eliminated_cleanup / attach_elimination_delta 日志，后续可直接核对 roleCount、buildingDelta、teamDelta、marchDelta、battleDelta。
补充修复记录：验收反馈“退出盐场再进会消失，过一会又出现”与问题16 同根，根因不是单次淘汰清理失败，而是后续战斗/行军/恢复路径把历史 member/memberV2 脏索引再次当权威写回。已补写侧不变量和运行时入口清洗，防止被淘汰/隐藏/死亡玩家通过 CompleteBattle、SettleRelayPvPMatch、CompleteMarch、StartBattle、StartAttackBuilding、RejoinMemberToLeaderHome 被重新放回建筑队列。状态改为待验证。

问题16：
状态：已修复，验收通过
现象：地图内突然出现很多人 点击挑战显示无法战斗 再次点击显示繁忙 退出游戏再进就会消失 过一会又会出现
预期：在就是在不在就是不在 能正常挑战敌方俱乐部玩家
截图：



修复依据：生产一区 2026-05-25 23:30-24:00 容器日志已轮转丢失，但 2026-05-26 00:00 归档快照仍保留问题现场：主战场快照 memberV2Total=105，其中 59 个成员真实状态为死亡/观战/可复活等不应驻守状态，67 个成员真实坐标为 -1_-1 或与建筑坐标不一致。客户端地图与队列由 building.memberV2 生成，Map 增量合并缺少删除标记不会清旧成员；服务端多个路径又把 member/memberV2 当权威回写，导致“重进消失，过一会又出现”。已统一定义建筑成员不变量：building.member/memberV2 只能由 roles.state + roles.position 推导，只有 idle/combat 且坐标等于建筑坐标、非 guest 的角色能保留。修复覆盖：CompleteBattle/SettleRelayPvPMatch 不再把非法成员重新置 idle；CompleteMarch 到达时先剔除幽灵守军；StartBattle 不再用幽灵 member 兜底改目标坐标，改为拒绝并清索引；StartAttackBuilding 判断敌方成员前先剔除非法成员；RejoinMemberToLeaderHome 不再把 watching/over/guest/march/combat 队员重进时写回大本营。新增 [bug16] 日志记录清理原因和入口。验证：新增集成测试 TestSettleRelayPvPMatch_DoesNotReIdleInvalidBuildingMember、TestStartBattle_RemovesGhostTargetInsteadOfRepositioning、TestCompleteMarch_PrunesGhostDefenderAndKeepsArrivalsIdle、TestStartAttackBuilding_PrunesGhostEnemyMemberBeforeEnemyCheck，并通过 GOCACHE=/tmp/xianyu-gocache go test . -run 'TestSaltfieldRoleAirshipID|TestSettleRelayPvPMatch|TestSanitizeBuildingMembersByPosition|TestRemoveRoleFromBuildingMembers|TestCompleteBattle_ReturnsActualRemovedBuildingDeltaForLoser|TestStartBattle_RemovesGhostTargetInsteadOfRepositioning|TestCompleteMarch_PrunesGhostDefenderAndKeepsArrivalsIdle|TestStartAttackBuilding_PrunesGhostEnemyMemberBeforeEnemyCheck' 与 GOCACHE=/tmp/xianyu-gocache go test ./domains/legion/war/saltfield。

问题17：
状态：已修复，验收通过
现象：和他人开战后 倒计时结束了 也一直是交战状态 不会结束 退出再进后恢复正常 战报内也不会显示这次交战
预期：和他人开战后 倒计时结束 会判定胜平负 不会出现这种一直卡交战情况
截图:

问题18：
状态：已修复 验收通过
现象：小队组队后 每次刨地 小队内每个人扣出5精力
预期：组队后 每次刨地 扣除小队内每人1精力
截图：
修复依据：测试服日志显示 StartAttackBuilding 开始时每名队员只扣 1 点精力，但建筑守卫 rightId=-1 仍进入车轮战结算，随后 SettleRelayPvPMatch 又按 PvP 规则额外扣 5，导致界面看到精力异常。服务端已增加 canRunBuildingRelayPvPLocked 判断，仅真实玩家防守方才进入车轮 PvP；守卫/占领建筑防守方不再进入 PvP 精力结算，只保留建筑攻击每人扣 1 点精力。

问题19：
状态：已修复，待验证
现象：盐场内和小队对战 不显示在交战列队里 且每次都是平局
预期：和小队交战也显示在小队里 和小队内每个人轮流进行交战
小队详细规则：同俱乐部成员可以组成小队，小队人数上限 5 人，队长负责小队所有行动

在未进场战斗时，可进行小队操作；如队长可以邀请、踢出队员、调整队员出战顺序；队员也可主动退出小队（入场后将无法进行操作）
个人积分获得及精力消耗仍以个人具体出战为准
小队将展示成员的在线状态
b. 队长：处于观战状态（已经复活但还未进入战场）的玩家点击「组队」或者左侧「小队」按钮，可邀请处于队员列表的玩家加入自己的小队
组队完成并且进场战斗后，只有当小队所有成员阵亡或者队长选择重生后，小队才会解散，所有成员才会回到重新布阵界面，否则小队仍受队长控制（即使仅剩 1 人存活；队长阵亡后仍控制小队）
队长选择重生复活时，小队所有仍存活的成员均会重生复活，此时小队将自动解散
队长负责全部小队成员的行军加速金砖消耗（每人每次 20 金砖）
c. 队员：处于观战状态的玩家（已经复活但还未进入战场）或者完全没有进入盐场的玩家会自动进入队员列表，在队员列表的玩家可被其他玩家邀请加入队伍（被邀请时默认 10s 后自动接受；接受后进入队员视角，直到小队解散）
未进行布阵玩家将默认采用上次布阵的阵容
拒绝邀请后，10s 内不会出现在队员列表
进场战斗后，队员在小队解散前无法脱离小队也无法重生
队员阵亡后仍会复活读秒，但只有小队解散后才能脱离小队重新布阵入场
d. 战斗
攻击城池守卫：小队成员同时攻击，小队战斗耗时与 1 人一致
小队战斗：根据出战顺序自动进行车轮战，直至一方人数耗尽或者平局才退出战斗（小队战斗时长略微削减）
队列详情中小队将作为一个整体展示，小队可被所有玩家展开查看其成员的信息

截图：

修复依据：生产一区 2026-05-28 日志显示小队轮战开战时 queueKeys 已写入 LW_WEEK-260528-day-3-week_round_1，但 startbattle_protocol_check 对该字符串 round battleKey 报 missing=[battleId]；普通数字 battleId 单人战 missing=[]。同日日志还显示最后一轮开始包 round=5 leftId=116563 rightId=709945，但最后一轮结束通知 roundId=…_round_5 winner=116563 loser=138021，结束字段与当前轮实际对手不一致。服务端已修复为每轮小队战将 round battleInfo 同步写入 battleList/battles，结束时清理对应 round key；最后一轮 War_EndBattleNotify 改用实际 roundLeftId/roundRightId/roundWinner/roundLoser 填 roleCodeId/targetCodeId/winCodeId/result，保留 teamWinId/teamLoseId 供团队维度识别。已补回归测试覆盖队列 battleInfo 和最后一轮 round 参战者字段。

问题20：
状态：已修复，验收通过
现象：和别人交战击杀别人后显示的战力会变化
预期：战力是多少永远显示多少 显示的战力不会变化 实际战力队对战 不显会更具精力多少变化
截图：

问题21：
状态：已修复，验收通过
现象：小队邀请列表里显示俱乐部所有玩家 且阵容战力都是一样的
预期：只有观战状态的玩家（已经复活但还未进入战场）或者完全没有进入盐场的玩家会自动进入队员列表，在队员列表的玩家可被其他玩家邀请加入队伍（被邀请时默认 10s 后自动接受；接受后进入队员视角，直到小队解散） 显示的阵容战力应该是队员自己预设的阵容
截图：



修复依据：生产一区 2026-05-28 日志显示 548996 的同俱乐部未进场成员被服务端 buildMockBattlefieldSnapshot 补进 roles/roleMap，客户端邀请列表按 roleMap 展示，随后 war_getteaminfo 对多个未进场成员 fallback 到同一套 friendly 阵容，导致列表出现未进场玩家且战力/阵容相同。服务端已改为未进盐场成员只保留 roleIds 积分占位，不再创建 roles/roleMap 可邀请角色；同时邀请入口拒绝未进场目标，历史快照中缺少 type=player/guest 的壳角色也不会再进入 roleMap。

问题22：
状态：已修复，验收通过
现象：排行榜内 俱乐部击杀榜不刷新 不记录
预期：正常记录每个俱乐部所有人员的击杀总和 并排行
截图：
修复依据：客户端俱乐部击杀榜 WarLegionKillRankingPage 直接读取 LegionWarBattleField.legionKillRankList，该列表按 battlefield.legions[*].killCnt 排序和显示。生产一区 2026-05-28 日志能看到服务端持续执行 applyBattleKillStats 并累加个人 winnerKillCnt，但没有俱乐部 killCnt 更新链路；服务端原结算只改 roles[winner].killCnt，未同步胜者所属 legions[legionID].killCnt，战斗结束增量也未下发 legions，所以俱乐部击杀榜一直为 0 或不刷新。现已在 PvP/接力 PvP 击杀结算中同步累加胜者俱乐部 killCnt，并在战斗结束通知中补 legions 增量；新增回归测试覆盖普通 PvP 完成后个人击杀与俱乐部击杀同步递增。