bug反馈7.4 ¶

问题1：
状态：已修复 待正式服确认
现象：俱乐部赛车每赛季结束后俱乐部段位不升级
预期：俱乐部赛车每赛季结束后 根据俱乐部排行榜名次 升级 保级 降级

• 各段位升降规则：
  青铜：前 6 名升段，其余不变
  白银：前 6 名升段，最后 2 名降段，其余不变
  黄金：前 6 名升段，最后 4 名降段，其余不变
  铂金：前 6 名升段，最后 6 名降段，其余不变
  钻石：前 6 名升段，最后 8 名降段，其余不变
  大师：后 14 名降段，其余不变
  同分排名优先级：俱乐部战力高者排名更高
  根因：客户端只展示服务端下发的 roleCar.dan/lastDan/isKing，不会本地计算俱乐部升保降；服务端赛车实现只做了个人赛季榜奖励结算，未加载 CarLegion 俱乐部段位规则，也没有在赛季结算点更新 roles.cargoRaid.dan 和 legion.dan。另外俱乐部排行榜同分时旧逻辑按俱乐部ID排序，不符合“同分俱乐部战力高者优先”。
  修复：服务端加载 CarLegion 升保降配置，在俱乐部结算时间后通过 car_getrolecar/car_getgrouprank 懒触发幂等结算；按段位内俱乐部排行榜计算升保降，排序规则为积分高优先、同分俱乐部战力高优先、再按俱乐部ID兜底；结算后持久化 roles.cargoRaid.dan/lastDan/danTime/isKing/lastIsKing 和 legion.dan，并记录 cargo_raid_group_dan_settlements 结算快照。首次进入赛车且没有 cargoRaid 数据的成员，会从所在俱乐部 legion.dan 初始化段位。
  问题回归建议：测试服准备每个段位20个俱乐部，构造排行榜积分覆盖前6、保级区、降级区，并额外构造两个同积分但俱乐部战力不同的俱乐部；赛季结算时间后分别打开赛车主界面和俱乐部排行榜，确认青铜前6升、白银后2降、黄金后4降、铂金后6降、钻石后8降、大师后14降，同分时高战力俱乐部排名靠前；同俱乐部多个成员重新登录后段位一致，未进过赛车的新成员首次进入也显示俱乐部结算后的段位。
  截图：
  
  

问题2：
状态：已修复 验收通过
备注：2026-07-05 验收通过
现象：”账号1：fafa id：791944 时间7.4 20：45 点击签到无反应
预期：签到面板只显示30天 点击签到可正常签到领取奖励 30天签到完成后 刷新为从第一天开始签到
截图：

现象：签到内30天31天无法正常领取 且不重置刷新签到天数
预期：每天可以正常签到正常领取奖励 签到最大天数为30天 30天签到完成后重置签到 从第一天开始 重新签到
根因：运行端配置仍存在 SignConf.31，客户端面板按 SignConf.list.length 显示 31 天；同时验收账号 fafa/791944 的 signInReward.29 是负数可领取标记，但服务端按角色创建时间取模计算到第16天，第16天已领取，于是 2026-07-04 20:45 连续 system_signinreward 请求都返回 code=1,msg=今日已签到。客户端非0响应没有提示分支，所以表现为点击无反应。
修复：服务端领取日优先使用现有负数可领取标记，避免和客户端展示态分裂；登录归一化和领取 handler 共用同一领取日逻辑；下发 signInReward 过滤 -1 和超过30天的旧键；清理工作区、测试服运行包、Web 发布目录中的 SignConf.31，测试服已重新发布。
问题回归建议：测试服用 fafa/791944 或同型数据验证第29天负数可领取时点击签到返回成功并弹奖励；验证签到面板显示 */30 且没有第31天；验证第30天领取后下一轮刷新为第1天；重复点击当天已领取时不重复发奖。
截图：

问题3：
状态：已修复 验收通过
现象：俱乐部成员内不显示离线时间
预期：正常显示成员离线时间 多久之前在线（类似好友截图2好友列表）
根因：俱乐部成员列表在线状态只判断集群在线，离线时优先使用成员快照里的 fallback online 值；该字段经常为空，未继续读取角色真实 LastOnlineAt，导致客户端拿不到离线时间。
修复：成员离线时改为读取角色缓存中的 LastOnlineAt 作为离线时间；在线玩家仍返回0，查不到有效时间时才返回-1。
问题回归建议：测试服准备同俱乐部在线成员、刚离线成员、长时间离线成员各1个，打开俱乐部成员列表，确认在线显示在线，离线成员显示“多久前在线”且和角色最后在线时间一致。
截图：

问题4：
正式服：账号LZBN2 ID:100089041 时间：7.3 15:12
状态：已修复 验收通过
现象：俱乐部攻打boss结算伤害和实际攻打伤害不一致
预期：攻打boss时 打出多少伤害就结算多少伤害
根因：军团Boss服务端走本地Go战斗引擎结算，客户端播放/弹窗使用的战斗结果来源不一致；同时服务端优先信任 accept.teamInfo.takeDamage，未以Boss战前后血量差作为结算权威值，导致排行榜/结算伤害可能和播放扣血不一致。
修复：军团Boss优先调用统一 battle-service 生成战斗结果，本地引擎只作为失败兜底；结算伤害统一按 startHP-curHP 计算，并回写 result.accept.teamInfo[0].takeDamage，保证弹窗、排行榜、扣血来源一致。
问题回归建议：测试服找同一俱乐部Boss连续攻打2次，分别记录战斗开始Boss血量、战斗结束Boss血量、结算弹窗伤害、俱乐部Boss伤害排行个人伤害增量，应满足每次“开始血量-结束血量 = 弹窗伤害 = 排行增量”；再验证击杀Boss时击杀奖励、排行奖励、Boss刷新状态正常。
截图：

问题5：
状态：已修复 待测试服回归
备注：测试服账号：rty520520 ID：100216517 时间：7.5号 17.55-17.58
测试服账号： As15917900 ID：100325939 时间 ：18：:00
现象：赢了判定输
预期：赢了就是赢了 输了就是输了 不会存在赢了判定输
截图：

备注：2026-07-05 追加定位并修复。验收不通过根因不是客户端判定，而是星级挑战 nmext_startboss 服务端没有走外部 client-js-worker 战斗，代码直接调用本地 runGenieFallbackBattle；测试服 17:56-17:58 三条 trace 只有 灯神回退战斗 日志，没有 battle worker result，其中 battleId=1783245419669 服务端本地判 isWin=false/rightHP=177835947877，但客户端用同一 battleData 播放到右侧 0HP，所以出现“赢了判定输”。已改为星级挑战优先调用现有外部 client-js-worker，失败时才本地 fallback，并补日志 nmext_startboss: battle worker result。2026-07-05 二次修正：客户端星级挑战布阵和战斗规则以 NightMareStarConf.monsters 作为右队来源，不是只用 legionBossShow 展示主 Boss；服务端上一轮筛成单主怪会造成服务端入参与客户端规则不一致，现已恢复按 monsters 全量构造右队，并继续保留 MonsterConf.attrs 到 battleData 的 attribute，技能/免控等仍由 MonsterConf.passive -> SkillSchemeConf -> SkillConf/BuffConf 配置驱动。2026-07-05 三次调整：按验收反馈将第 2 关楚江王主怪 LevelCoeffConf.331002.attkCoeff 减半，实际战斗攻击从约 6298456126 调整为约 3149228063，血量、速度、抗性、免控和两个随从不变。
问题回归建议：测试服逐关进入十殿星级挑战 1-8 关，记录战斗内右侧 HP、攻击/速度表现、右侧战力显示和战斗是否可正常结算；第 1、2、5 关右侧阵容应与客户端布阵面板 monsters 一致，不能只剩 legionBossShow 单主怪；第 2 关楚江王主怪基础攻击应为约 3149228063、血量 247926608648，并带两个随从行；第 6 关确认 HP 为 150、速度为 2；任意能打赢的局必须弹“挑战成功”，不能出现右侧 0HP 仍“挑战失败”；服务端日志应出现同 battleId 的 nmext_startboss: battle worker result ... engine=client-js-worker。
现象：十殿内星级挑战boos属性不对
预期：每一关boss属性正确
第一关：秦广王
攻击：57亿
血量：2253亿
速度：13000
破甲抵抗：70
暴击抵抗：50
破甲：70
精准：70

第二关：楚江王
攻击：63亿
血量：2479亿
速度：13500
破甲抵抗：70
暴击抵抗：50
破甲：70
精准：70
免控：80

第三关:宋帝王
攻击：69亿
血量：2727亿
速度：13600
破甲抵抗：70
暴击抵抗：50
破甲：70
精准：70
免控:80

第四关：五官王
攻击：76亿
血量：2999亿
速度：13600
破甲抵抗：70
暴击抵抗：50
破甲：70
精准：70
免控：80

第五关：阎罗王
攻击：84亿
血量：3299亿
速度：13600
破甲抵抗：70
暴击抵抗：50
破甲：70
精准：70
免控：80

第六关：卞城王
攻击：115亿
血量：150
速度：2
破甲抵抗：70
暴击抵抗：50
破甲：70
精准：70
免控：80

第七关：泰山王
攻击：229亿
血量：7512亿
速度：13600
暴击：100
破甲抵抗：70
暴击抵抗：50
破甲：70
精准：70
免控：80

第八关：都市王
攻击：137亿
血量：7888亿
速度：15000
破甲抵抗：100
暴击抵抗：60
破甲：100
精准：50
免控：85
冰冻免疫：100
沉默免疫：60
截图：

问题6：
状态：已定位 服务端侧已修待发布回归
备注2：测试服账号：测试服 rty520520 ID：100216517 时间：7.5号 19:16
现象：两边都显示本局对战结束 房主点击开启对战显示请等待场上玩家战斗结束
预期：战斗结束后 点击开启对战 可以正常开启新一轮对战
截图：

备注：2026-07-05 复查 19:16 测试服日志，房间 449894002、房主 100216517、队员 100518971。19:13:57 开战，外部战斗返回 totalFrame=5559，服务端原逻辑按 totalFrame/30 延迟结算，即约 185 秒，导致房间一直保持 active battle；19:17:02 才执行 pkroom_finishbattle 释放房间。截图时间点客户端已显示本局结束，但服务端仍未结算，所以房主再次开战会被“场上玩家战斗未结束”状态挡住。该问题按服务端问题处理，已改服务端：房间战斗结算延迟保留最小 3 秒，并增加 10 秒上限；同时补充 pkroom_startbattle_finalize_schedule、pkroom_finishbattle、pkroom_getfightroomdetail_active、pkroom_startbattle reject room not wait 日志，后续可直接按 roomId/battleId 验证是否仍被 active battle 卡住。本次未改客户端。备注：此前 120 秒上限仍长于客户端结算倒计时，问题14已证明需要进一步压到 10 秒。

备注：测试服账号： As15917900 ID：100325939 时间 ：18：10
现象：队员看到的画面依旧不对
预期：对战时队员看到的页面正常 不重叠
截图：

备注：2026-07-05 复查测试服 18:10 账号 As15917900 / 角色 100325939。房间 445909001、战斗 1783246219715 日志显示 pkroom_fightnotify_payload 对房主 100216517 和队员 100325939 推送的是同一份 payload：attackRoleId=100216517 defendRoleId=100325939、leftRoleId=100216517 rightRoleId=100325939、比分 100216517:1-100325939:0，协议日志显示房主 pkroom_startbattle 响应 extraPushCount=1，队员通知已送达。验收截图里战斗层已打开，但房间面板的“全员已准备 / 点击进入观战”、底部资源栏、返回按钮仍叠在战斗层上；对照客户端 RoomFightModule._onRoomFightNotify、RoomFightPanel._onNewBattle，收到新战斗只 SHOW_BATTLE_UI，没有关闭/隐藏 RoomFightPanel。因此当前验收不通过不是服务端左右镜像 payload 问题，剩余根因是客户端房间层未在新战斗事件里关闭/隐藏。按“不改客户端”要求，本轮不改客户端代码；若允许改客户端，建议在 RoomFightPanel._onNewBattle / BattleRoomBasePanel._onNewBattle 打开战斗前关闭或隐藏房间面板，并在战斗结束/重连路径恢复。

备注：2026-07-05 定位并修复服务端侧。根因是 pkroom_fightnotify 对防守方/队员按观看者做了镜像 payload，交换 attackRoleId/defendRoleId、分数、左右队伍和战斗结果，导致房主与队员看到的左右阵营/比分不一致。生产一区 2026-07-04 21:55 房间 373177029 日志显示对队员 100089014 推送 mirrored viewer，队员收到 attackRoleId=100089014 defendRoleId=100316514，而房主视角是 attackRoleId=100316514 defendRoleId=100089014，与截图左右翻转一致。已改为所有成员、观战者、重连重放都收到同一份开战 payload。按要求本次未改客户端；若仍出现房间 UI 叠在战斗层上，需要单独处理客户端 RoomFightPanel 收到新战斗后未关闭/隐藏房间层的问题。
问题回归建议：测试服建高级对战房，至少 2 名队员进入并准备，房主连续开 3 局；房主、队员、观战者同时截图或录屏，对比双方昵称、战力、左右位置、比分、回合数必须一致；队员刷新/重连后调用房间详情，应继续看到同一份战斗左右关系；若仅剩“房间按钮/准备状态覆盖战斗层”，按客户端残留问题另开处理。
现象：对战房间高级对战房间开启后 只有房主看到的界面正常 队员看到的界面不正常
预期：房主队员 观战人员看到的界面一致 不会卡屏 （截图1为房主界面 截图2为队员界面）
截图1：
截图2：

问题7：
状态：未处理
现象：竞技场内存在赢了判定输的情况 竞技场内鱼珠定心只有第一回合生效
正式服账号：rty520520 密码rty5644040 ID：100216517 时间：7.5 15.10-15.12
预期：竞技场内战斗赢就是赢 输就是输 不存在赢了判定输 输了判定赢 鱼珠定心在任何战斗内有正常生效 百分之80概率免疫降怒气
截图：

问题8：
状态：验收通过
现象：冠名播报和世界播报所有人看到的不一致 一区和五区有两个账号看到的播报永远只有自己和别人不一样
5区账号：帐号：zgl333450 密码：ligen840915 UID：500650215
1区账号：账号：facaizzz 密码：zzz1226 uid：100316514
预期：所有人看到的播报名字都一样 根据金额排名 不会存在只能自己看到自己的情况
根因：同一个运行区服内存在基础服和子服 serverId，例如一区 26501/1026501/2026501，五区 28501/1028501/2028501。登录运行服校验已按 base serverId 归并，但 sponsor 冠名/前三播报仍按 charge_orders.serverId 原始值精确分榜，并且在线推送也用 client.serverId == serverId 精确过滤，导致同一运行区内不同子服玩家看到不同冠名和不同“本区赞助金额前三”。生产只读证据：一区 100316514 是 1026501，看到 发发发发发财/62210.01元 子服榜；同一区基础服榜是 发财是给/77888元。五区 500650215 是 1028501，看到 俱乐部招大哥/38817元 子服榜；五区基础服榜是 地主/34000元。截图中的两套名字与生产 sponsor_naming_state 和 charge_orders 分桶完全一致。
修复：服务端 sponsor 模块读订单、列可结算服、读写冠名状态、结算记录、广播记录时统一使用运行区 base serverId；订单数据不迁移，读取时按同运行区子服集合聚合。世界小喇叭和冠名跑马灯推送改用 SameRuntimeServerID 匹配在线客户端，不再按原始 client.serverId 精确相等过滤。
问题回归建议：发布后在一区分别用基础服玩家和 100316514/facaizzz 登录，等待 sponsor 冠名跑马灯和世界小喇叭，确认看到同一套一区榜；在五区分别用基础服玩家和 500650215/zgl333450 登录，确认看到同一套五区榜。一区预期按同运行区总榜显示 发财是给 第一，五区预期按同运行区总榜显示 俱乐部招大哥 第一；同一时间不同账号截图的冠名跑马灯和世界频道系统气泡内容必须一致。
截图：一区所有人看到的：
一区ID：100316514看到的：、
5区所有人看到的：
5区UID：500650215看到的：

问题9:
状态：已核查，待 2026-07-06 00:01 后回归确认
现象：正式服内竞技场每日奖励每周奖励不发放 （测试服会正常发放）
预期：正式服内竞技场每日奖励 每周奖励会根据排名 通过邮件正常发放
核查结论：当前生产一区证据未复现“不发放”。每日奖励 2026-07-05 00:01 已结算并发送，生产日志有 arena reward settle summary: rewardType=1 stamp=1783173600 sent=6764 skipped=4563，Mongo 邮件表有 6764 封 竞技场每日奖励。上一轮周奖励 2026-06-29 00:01 已发送，Mongo 邮件表有 6552 封 竞技场赛季奖励。当前截图是 2026-07-05 周日结算前，客户端也显示“保持排名至周日22点可获得以下奖励（0点发放）”，本周奖励/晋级/积分重置应在 2026-07-06 00:01 执行。
问题回归建议：2026-07-06 00:01 后检查生产一区 竞技场赛季奖励 邮件数量、arena_rewards 周奖励 sent 状态、arenaScore=1000 重置和赛季场次变化；若仍无邮件或未重置，再按具体 roleId/时间补查日志。
截图：

问题10：
状态：已修复，验收通过
现象：佩戴宠物和玩具时 攻打俱乐部boss不显示 不生效
预期：攻打俱乐部boss时正常显示玩具宠物ui 正常生效
根因：客户端 LegionModule.startLegionBoss 发送 fight_startlegionboss 时请求体为空，生产一区日志也显示近期该命令 bodyBytes=2。服务端俱乐部 BOSS 的 fight_startlegionbossresp.buildPlayerTeam 没有像竞技场/山海经等战斗一样从角色当前装备补默认玩具和宠物：weaponId 直接使用请求值导致为空时为 0，weaponActiveLevelId 固定 1050，并且未调用 rolepetx.DecorateTeamWithPet。客户端战斗 UI 只读 battleData 的 leftWeaponId/leftPetActiveSkillId 等字段，所以俱乐部 BOSS 不显示且战斗数据不带宠物效果。
修复：服务端俱乐部 BOSS 组队构造在请求未带玩具时使用角色 LordWeaponId，按当前武器计算 weaponActiveLevelId，并使用已上阵宠物补齐 pet/petUId/petActiveSkillId/petPassiveSkillIds 到 leftTeam；未修改客户端。
验证：新增并通过 TestFightStartLegionBoss_BuildPlayerTeamIncludesDefaultWeaponAndPet；已通过 go test . -run 'TestFightStartLegionBoss_BuildPlayerTeamIncludesDefaultWeaponAndPet|TestBuildNightmareStarBattle_UsesBattleWorkerResult' -count=1 和 go test ./internal/gameplay/legionbossx -count=1。
问题回归建议：发布后用已佩戴玩具和已上阵宠物的账号进入俱乐部 BOSS，确认底部出现玩具/宠物技能按钮，点技能可释放；再查看同一场战斗伤害/战报，确认宠物主动/被动字段已进入 battleData。对照普通关卡截图，俱乐部 BOSS 不应再只有“跳过/倍速”按钮。
截图：

问题11：
状态:已核查，待 2026-07-06 00:01 后回归确认
预期：确保周一竞技场会根据排名正常晋级场次 所有人积分会重置为1000
核查结论：服务端配置的周流程是周日 22:00 快照、周一 00:01 发周奖励并执行晋级/降级和积分重置；截图时间仍是 2026-07-05 周日，面板显示“5小时后本周挑战结束”，当时尚未到重置时间。生产一区 2026-07-05 22:01 已生成本周周榜快照日志：arena reward snapshot summary: rewardType=2 stamp=1783260000 snapshotted=12639 skipped=0 ranked=12639，发奖/重置需等 2026-07-06 00:01。
问题回归建议：2026-07-06 00:01 后检查生产一区周奖励发送日志、arena_rewards 周奖励 sent 状态、玩家 arenaScore 是否重置为 1000、场次是否按周排名晋级/保级/降级；截图中的账号可作为优先回归样本。
截图：

问题12：
状态：已修复，验收通过
账号：facai005 ID：500229314 时间：7.5号 17:02
现象：正式服内点击升级挂机奖励非常卡顿 会出现转圈圈
预期：点击升级挂机奖励 流畅不卡顿
根因：截图右上角为 28501，实际对应生产五区。生产五区 2026-07-05 17:00-17:03 该账号没有服务端 handler 卡死或超时，system_hangupupgrade 最大 e2e 约 81ms，system_activehanguporder 最大 e2e 约 200ms；但升级按钮成功后客户端会自动触发激活订单，请求非常密集，同窗口 system_hangupupgrade 10 次、system_activehanguporder 46 次。服务端两条路径都返回 GetOptimizedRole 大包：升级单包约 345KB，激活订单单包约 600KB，3 分钟累计约 32MB，客户端连续解码/合并大包导致面板转圈卡顿。
修复：服务端不改客户端。system_hangupupgrade 保存后只返回挂机面板必需的 role.hangUp 和 role.items["1024"]；system_activehanguporder 保存后只返回 role.hangUp/roleInfo.hangUp，仍调用 UpdateRoleAfterChange 刷新优化基线，但不再读取/返回整包角色差异。
验证：新增并通过 TestBuildHangUpUpgradeResponse_ReturnsHangUpAndUpgradeItemOnly、TestBuildActiveHangUpOrderResponse_ReturnsOnlyHangUpDelta、TestBuildActiveHangUpOrderResponse_UpdatesWithoutReadingOptimizedRole；已通过 go test . -run 'HangUp|hangUp|ActiveHangUp|system_hangup' -count=1。
问题回归建议：发布后用 facai005/500229314 或同类高等级挂机账号连续点击升级，观察面板不再长时间转圈；生产日志中 system_hangupupgrade 响应体应从约 345KB 降到小包，system_activehanguporder 应从约 600KB 降到小包，客户端道具 1024 数量、挂机等级和激活订单仍正常刷新。
截图：

问题13：
状态：未处理
账号：facai005 ID：500229314 时间：7.5号 17:05
现象：正式服内点击俱乐部赛车排行会出现卡死转圈圈情况
预期：点击俱乐部赛车内排行榜 流畅不卡顿
截图：

问题14：
状态：已修复， 验收通过
测试服账号：rty520520 ID：100216517 时间：7.5 22:44
现象：一局对战结束后 结算倒计时完成 点击开始对战显示请等待场上玩家战斗结束 过一分钟左右才能正常开启对战
预期：一局结束后 结算倒计时结束后 立即可以开启新对战
根因：与问题6同一条链路，不是客户端问题。测试服日志显示房间 462543002 在 2026-07-05 22:42:56 开战，battle worker 返回 totalFrame=4429，服务端按旧修复后的上限仍设置 delaySec=120；直到 22:44:56 才 pkroom_finishbattle 释放 active battle。22:43:30-22:44:56 未见 pkroom_startbattle 到达服务端，说明客户端开始按钮因本地 roomInfo.state == fight 直接提示“请等待场上玩家战斗结束”。问题6的 120 秒封顶仍长于客户端结算倒计时，因此属于问题6根因未彻底修干净。
修复：服务端高级对战房战斗释放延迟仍保留 3 秒最小保护，但最大上限从 120 秒压到 10 秒；战斗结果、胜负和结算仍按服务端已拿到的 battle result 执行，只缩短房间可开启下一局的 active battle 占用时间。本次未改客户端。
验证：新增/调整 TestPKRoomBattleFinalizeDelay_CapsLongBattle，覆盖普通长战斗和 totalFrame=5559/4429 这类长帧战斗都会被压到 10 秒；已通过 go test . -run 'TestPKRoomBattleFinalizeDelay_CapsLongBattle|TestApplyPKRoomBattleOutcome|TestPKRoomStartBattleHandler' -count=1。
问题回归建议：发布后用 rty520520/100216517 在高级对战房打一局，客户端结算倒计时结束后 10 秒内应可重新开始；测试服日志应看到 pkroom_startbattle_finalize_schedule ... rawDelaySec=147 delaySec=10 capped=true，随后约 10 秒出现 pkroom_finishbattle，不应再等待约 120 秒。
截图：