bug反馈 2026.5.4 ¶

问题1：
状态：已修复
现象：挂机奖励里 升级后无法激活 点击激活无反应
预期:正常激活
截图：
修复：根因是客户端 HangUpDialog 激活按钮调用 system_activehanguporder 后只通过 syncresp/role.hangUp 刷新按钮状态；服务端 system_activehanguporderHandler 已保存 activeOrder，但 buildActiveHangUpOrderResponse 保存后再读取优化差异，返回里没有 role.hangUp，日志中 2026-05-06 13:14:21/13:14:22 多次 system_activehanguporder 完整响应只有 statistics/statisticsTime，导致客户端收不到 SyncHangUp，看起来点击无反应。已改为激活订单响应强制带回最新 role.hangUp，并保留优化层已有字段。
验证：查看了问题截图、HangUpDialog/HangUpModule 客户端调用、core/hangup 与 system_activehanguporder 服务端链路、gm_server.log 中 system_activehanguporder 响应；已运行 env GOCACHE=/tmp/go-build go test . -run TestBuildActiveHangUpOrderResponse_UpdatesBeforeReadingOptimizedRole 通过。

问题2：
状态：已修复
现象:幽冥十殿奖励发放到邮箱后 无法领取 点击领取无反应
预期：正常领取奖励
截图：

修复：根因是幽冥试炼排行奖励邮件由 sendNightmareRaceRewardMail 生成时，把 NightMareRaceRankRewardConf.finalReward 中的玩法展示类型原样写入邮件附件；配置内存在 type=22、type=24，邮件领取链路 applyMailAttachmentReward 不支持这些附件类型，会返回“暂不支持的邮件附件类型”，客户端只表现为领取无反应。已在发邮件阶段将 22/24 归一为邮件可领取的普通道具附件 type=3，同时领取阶段兼容已入库的历史 22/24 附件，确保旧邮件也能领取。
验证：查看了问题截图、MailModule 客户端 claimAttachment/claimAllAttachment 调用、mail_claimattachment/mail_claimallattachment 服务端链路、幽冥试炼排行奖励发邮件代码和 NightMareRaceRankRewardConf 配置；已运行 env GOCACHE=/tmp/go-build go test . -run 'Test(BuildActiveHangUpOrderResponse_UpdatesBeforeReadingOptimizedRole|BuildNightmareRaceMailAttachment_NormalizesDisplayRewardTypes|ApplyMailAttachmentReward_AcceptsLegacyNightmareRaceTypes)' 通过。

问题3：
状态：已修复
现象：预设多套阵容时 从槽位1 换到槽位2 或者切换到别的槽位阵容后 去动俱乐部科技 数值就会崩
预期：切换布阵后应显示当前阵容的正确战力值
截图：

修复：根因是预设阵容切换成功后，服务端 presetteam_saveteamHandler 清掉了 roleOptimized 的差异检测器；下一次再点击俱乐部科技 legion_research 时，GetOptimizedRole 会把这次请求当成首次取角色，直接返回全量带动态加成的 role/所有 heroes。客户端 RoleDataView 会把这些加成后的英雄属性同步到本地显示层，表现为切换阵容后动俱乐部科技数值异常放大。已改为预设切换保存后调用 UpdateRoleAfterChange，把优化差异基线更新到切换后的当前角色，不再清空基线，后续俱乐部科技只返回本次科技变化需要的差异。
验证：查看了问题截图、客户端 LegionResearchDialog/RoleDataView 同步逻辑、预设阵容 presetteam_saveteam 服务端链路、俱乐部科技 legion_research 服务端链路、roleopt 优化差异逻辑；服务端日志中 2026-05-04 23:07:21 切换预设后，23:07:48 的 legion_research 返回 role len=220 全量角色，符合该根因。已运行 env GOCACHE=/tmp/go-build go test . -run 'Test(BuildActiveHangUpOrderResponse_UpdatesBeforeReadingOptimizedRole|BuildNightmareRaceMailAttachment_NormalizesDisplayRewardTypes|ApplyMailAttachmentReward_AcceptsLegacyNightmareRaceTypes)' 通过。

问题4：
状态：已修复
现象：例如槽位1是原阵容 开了槽位2 阵容1的武将无损切换到阵容2的武将后 回到阵容1 阵容2的武将还保容着武将等级和淬炼等 卡出了多套淬炼 武将全部满等级
预期：阵容2切换回阵容1后 阵容2原武将 等级淬炼应回到原状态
截图：
修复：根因是服务端预设阵容快照只保存上阵 teamInfo，不保存非上阵武将的背包状态。切到槽位2时，槽位2的武将会按该槽位快照获得等级、装备、淬炼等；再切回槽位1时，服务端只恢复槽位1上阵武将，并把槽位2武将下阵，没有恢复槽位1快照下该武将原本的背包等级/装备/淬炼，导致槽位2武将继续保留满级和淬炼。已给 PresetTeamSnapshot 增加 bagHeroInfo，保存当前槽位下所有非上阵武将的状态，切换预设时先恢复目标槽位 bagHeroInfo，再恢复 teamInfo，确保被换下的武将回到该槽位应有状态；客户端 getInfo 也会返回 bagHeroInfo。
验证：查看了问题截图、客户端 HeroTeamPanel/HeroModule 预设切换调用、服务端 BuildPresetTeamSaveTeamResponse/applyPresetSnapshotToRole 快照恢复逻辑；新增 TestBuildPresetTeamSaveTeamResponse_RestoresBagHeroSnapshot 覆盖“槽位2满级武将切回槽位1后恢复背包状态”。已运行 env GOCACHE=/tmp/go-build go test ./domains/social/team ./domains/legion/tech 通过。

问题5：
状态：已修复
现象：使用一键换阵后 水晶等级依然会丢失 满等级回到未解锁状态
预期:水晶等级不会丢失
截图：
修复：根因是服务端 PresetHeroSnapshot 模型已有水晶字段 curTrump、trumpId2、transTrumpId2，但预设阵容保存、克隆、恢复和回包只处理了 trumpId、transTrumpId、tt，第二套水晶和当前水晶选择漏同步。一键换阵/预设切换后，客户端收到的武将缺少第二水晶等级字段，就显示为未解锁。已补齐 curTrump/trumpId2/transTrumpId2 的保存、克隆、冲突释放、恢复和回包。
验证：查看了问题截图、客户端水晶显示字段、服务端 PresetHeroSnapshot 模型与 preset.go 保存/恢复链路；已扩展 TestBuildPresetTeamSaveTeamResponse_AutoMovesNightmareIdsToTargetHero 覆盖 curTrump/trumpId2/transTrumpId2。已运行 env GOCACHE=/tmp/go-build go test ./domains/social/team -run 'TestBuildPresetTeamSaveTeamResponse_(AutoMovesNightmareIdsToTargetHero|RestoresBagHeroSnapshot)' 通过。

问题6：
状态：已修复
现象：例阵容1战力40亿 阵容2战力60亿 从阵容1切换到阵容2后 战力显示是阵容1的40亿 战力不会实时变化 需要去动一下战力才会恢复原战力
预期：切换到哪个阵容就显示哪个阵容的战力
截图：

修复：根因是客户端 HeroTeamPanel 在当前布阵页显示的是 ROLE.calculatePower，也就是 RoleDataView.power；服务端 presetteam_saveteam 切换预设成功时只回 battleTeam/heroes/lordWeaponId 等字段，没有回当前目标阵容的 role.power，因此客户端继续显示切换前阵容的战力，直到后续升级/科技等协议带回 power 才刷新。已在 BuildPresetTeamSaveTeamResponseWithPower 中按目标 battleTeam 计算当前阵容 power，并放入 role/roleInfo 回包。
验证：查看了问题截图、客户端 HeroTeamPanel.refreshPower 和 RoleDataView.updateValue、服务端 presetteam_saveteam 回包；已扩展 TestBuildPresetTeamSaveTeamResponseWithPower_ReturnsDynamicPresetPower 校验切换预设响应包含当前阵容 power。已运行 env GOCACHE=/tmp/go-build go test ./domains/social/team -run 'TestBuildPresetTeamSaveTeamResponseWithPower_ReturnsDynamicPresetPower' 通过。

问题7：
状态：已修复
现象：黑市内 商品价格不对 而且每次刷新价格都会变
预期：商品价格正确且没折扣情况下价格不变
截图：



修复：根因是客户端 SingleGoodData.price 直接使用 serverData.discount 作为价格倍率，服务端 store_goodslist/store_refresh/store_buy 回包却把折扣下发成 7/8/10 这样的展示档位，导致客户端按 7 倍、8 倍、10 倍计算价格；同时 discount 显示值又会变成 70/80/100，折扣角标被隐藏，看起来就是“没折扣但价格每次变”。已把服务端黑市折扣协议值统一为客户端需要的倍率 0.7/0.8/1，并覆盖 store_goodslist 的 storex 路径和 store_refresh/store_buy 的 systemx 路径。
验证：查看了四张黑市截图、客户端 ShopModule/MarketContentDialog 价格与折扣显示逻辑、服务端 app-2026-05-04.log 连续 store_goodslist/store_refresh 日志、服务端 storex/systemx 代码；已新增/调整折扣协议单测。已运行 env GOCACHE=/tmp/go-build go test ./internal/commerce/storex ./internal/systemx 通过。

问题8：
状态：已修复
现象：俱乐部信息里和俱乐部内 不能正确显示玩家名字 显示的是玩家的数字id
预期：正常显示玩家设置的游戏名字
截图：


修复：根因是俱乐部 members 里保存的是加入/创建俱乐部时的成员快照，legion_getinfo 和 legion_getinfobyid 直接用 member.name 下发；当历史数据或测试数据把 member.name 写成 roleId，或者玩家之后改名，服务端不会从当前角色表修正，所以客户端 LegionInfoDialog/LegionDetailsDialog 按 a.name 显示成数字。已在俱乐部读路径增加成员资料同步：读取俱乐部信息时按成员 roleId 加载当前角色名、头像、头像框、名片和服信息，修正 members 快照并回写俱乐部，再下发给客户端。
验证：查看了三张截图、客户端 LegionInfoDialog/LegionDetailsDialog/LegionModule 显示字段、服务端 legion_getinfo/legion_getinfobyid 代码和 2026-05-04/2026-05-05 服务端日志。已新增 TestSyncMemberProfiles_UsesCurrentRoleName，并运行 env GOCACHE=/tmp/go-build go test ./domains/legion/read 通过。

问题9：
状态：已修复
现象：刚退出一个俱乐部 在申请别的俱乐部 显示申请成功 但是进不去 且可以立马创建新的俱乐部
预期：自己退出俱乐部会有12小时冷却 再次申请俱乐部会显示冷却倒计时 需要等12小时冷却过后才可以加入新俱乐部 或者创建俱乐部 如俱乐部设置有审核 需要团长或者副团长同意申请才可以进俱乐部
截图：
修复：根因一是服务端 Leave 只设置 LegionCdTime，未设置 LegionCreateCdTime，导致退出后申请加入会被冷静期拦截，但创建俱乐部仍可立即成功；2026-05-05 14:02:31 退出后 14:03:02/14:04:07 legion_applyjoin 已返回 code=4 冷静期，和 13:19/19:18 的 legion_create 成功日志能对上。根因二是客户端会调用 legion_directjoin，但服务端未注册该协议，日志显示“未找到协议处理器”后返回空 map，客户端容易走成功分支。已改为退出时同时写入加入/创建 12 小时冷却，并注册 legion_directjoin，冷却中返回 code=4。
验证：查看了截图、客户端 LegionModule.sendApplyJoin/sendOneKeyJoin/sendCreateLegion/sendLevel、服务端 member Leave/CanJoin/CanCreate/HandleCreate/HandleApplyJoin、2026-05-05 服务端日志。已运行 env GOCACHE=/tmp/go-build go test ./domains/legion/member ./entry/account/wsentry 和 env GOCACHE=/tmp/go-build go test . -run 'TestBuildActiveHangUpOrderResponse_UpdatesBeforeReadingOptimizedRole' 通过。

问题10:
状态：已修复
现象：俱乐部信息内俱乐部红淬和个人红淬显示不正确
预期：根据当前玩家上阵武将显示正确红淬数量 个人最大为100
截图：

修复：根因是服务端 countRoleActiveTeamRedQuenches 复用了梦魇 helper，当前上阵队伍红淬数为 0 时会回退到 role.RedQuenchCnt 历史总数；截图中个人显示 135、俱乐部显示 5595，而角色阵容红淬角标实际为 0，正是这个回退导致。已为俱乐部展示改用严格统计当前上阵武将装备红淬，不再回退历史总数，并按个人最大 100 截断。
验证：查看了四张截图、客户端 LegionInfoDialog/LegionDetailsDialog 展示的 battle_red_quench_cnt/quenchNum 字段、服务端 legion_getinfo/legion_getinfobyid 红淬统计链路和日志。已新增 CountActiveTeamRedQuenchesExact 测试，运行 env GOCACHE=/tmp/go-build go test ./internal/nightmarehelpers ./domains/legion/read 和 env GOCACHE=/tmp/go-build go test . -run 'TestBuildActiveHangUpOrderResponse_UpdatesBeforeReadingOptimizedRole' 通过。

问题11：
状态：已修复
现象：俱乐部成员有解散俱乐部选项 且点击后显示进入解散冷静期
预期：只有俱乐部团长才可以解散俱乐部
截图：
修复：根因是服务端俱乐部成员职位快照存在脏值，签到兜底 EnsureMember 会写入 job=0，历史成员也可能出现非会长 job=1；客户端 LegionDetailsDialog/LegionMembersDialog 完全依赖服务端下发的 self.job 和 member.job 控制解散、管理、踢人按钮，因此普通成员会被显示成高权限。更严重的是服务端 Dissolve 权限判断用了“member.Job == 1 或 leaderId 是本人”的放行条件，非会长脏 job=1 也能进入解散流程。已增加服务端成员职位归一化：leaderId 对应成员强制 job=1，非会长非法值/脏 job=1 降级为普通成员 job=999，并在 legion_getinfo、legion_getinfobyid、kickout、changejob、dissolve 前执行并回写；Dissolve 改为必须同时满足 job=1 且 roleId==leaderId。
验证：查看了截图、客户端 LegionDetailsDialog 解散按钮和 LegionMembersDialog 管理权限逻辑、服务端 member/manage/read 代码、2026-05-05 legion_getinfo/dissolve/kickout 日志摘要；已运行 env GOCACHE=/tmp/go-build go test ./domains/legion/member ./domains/legion/read 通过。

问题12：
状态：已修复
现象：俱乐部成员可以踢人 俱乐部现在团长 副团长 队员显示的图标都是一样的
预期：只有俱乐部团长和团长任命的副团长才有踢人权限 团长 副团 队员权限分明
截图：
修复：同问题11根因，客户端职位图标、职位下拉和删除按钮都依赖服务端下发的 job；成员快照里 job=0/job=1 脏值导致职位显示和权限按钮错乱，服务端 Kickout 也直接信任 operatorMember.Job。已在踢人/改职位前统一 NormalizeMemberJobs，非 leaderId 成员不能再凭脏 job=1 获得踢人权限；签到兜底新建成员也从 job=0 改为普通成员 job=999，避免继续产生脏数据。
验证：查看了截图、客户端 LegionMembersDialog _refreshMember 中 self.job < member.job 和 leaderId 管理判断、服务端 Kickout/ChangeJob/EnsureMember 链路及服务端日志；新增 DirtyNonLeaderJobCannotKick、NormalizeMemberJobs、GetInfoByID 职位归一化测试，并运行 env GOCACHE=/tmp/go-build go test ./domains/legion/member ./domains/legion/read 通过。

问题13：
状态：已修复
现象：所有金鱼获取后 图鉴无法点亮
预期：金鱼获取后 可以正常点亮图鉴 根据金鱼星级点亮对应图鉴星级
截图：

修复：根因是客户端 BookModule/ArtifactBookDataView 判断鱼灵图鉴是否可点亮只看 ROLE.artifactBooks；服务端只在 artifact_lottery 后按背包 items 生成 artifactBooks，登录/图鉴信息请求不会从已拥有鱼灵补齐，而且已装备在武将、珍珠上的鱼灵不在 items 里。截图里鱼缸已有金鱼，但鱼灵图鉴显示 0/69，就是 artifactBooks 缺失导致客户端仍处于 lock。已把服务端图鉴修复扩展为从背包 items、武将 heroes.artifactId、珍珠 pearlMap.artifactId 三个来源生成 artifactBooks；登录回包和 collection_getinfo 都会修复、持久化并下发 artifactBooks，artifactBooks 变化也会触发收藏/图鉴刷新通知。
验证：查看了截图、客户端 BookModule/ArtifactBookDataView 激活状态逻辑、服务端 artifact_lottery、book_upgradeartifact、collection_getinfo、登录 role payload 代码和 2026-05-05 artifact/collection 服务端日志。已新增 EnsureArtifactBooksFromOwnedArtifacts 测试，并运行 env GOCACHE=/tmp/go-build go test ./internal/artifactutil ./internal/artifactx ./entry/growth/bookentry 和 env GOCACHE=/tmp/go-build go test . -run TestCollectionNotifyKeysChanged 通过。

问题14：
状态：已修复
现象：咸神竞技场内 每次挑战 列表内只出现一人 剩下的是空白 且点击挑战无反应 不能正常挑战
预期：挑战列表内人数正常 且可以正常挑战
截图：

修复：用户确认该问题已修复，本轮跳过复查。

问题15：
状态：已修复
现象：四圣共鸣升级时 会出现升级一次增加百分之20以上的词条 有时升级一次增加百分之百
预期：四圣升级 正常一次加百分之一 暴击最高加百分之20
截图：

修复：根因是服务端 hb_quench 共鸣增量按固定属性基准再乘倍率写回 hB；一阶上限为攻击 409、生命 6887、速度 40，20 倍暴击时固定基准会让单次提升接近或达到 100%，服务端日志 2026-05-05 19:55:09 也能看到 hb_quench 返回 multi=20。客户端 HolyBeastData 按当前阶最大属性显示进度，因此该服务端增量会表现为“一次涨 20% 以上/直接满”。已改为服务端按本阶属性上限的百分比计算增量：1 倍为 1%，20 倍最高为 20%，并保留属性上限截断。
验证：查看了两张截图、客户端 HolyBeastSkinModule/HolyBeastData 共鸣调用和进度显示、服务端 hb_quench/hbx.QuenchFieldized 计算链路、2026-05-05 服务端 hb_quench 日志；已增加 20 倍暴击只增加上限 20% 的回归测试。

问题16：
状态：已修复
现象：挑战深海灯神时挑战赢了判输
预期：赢就是赢 输就是输 不会赢了判定输
截图：

修复：根因是客户端 FightService.startGenie 拿服务端 battleData.result.isWin 决定结算弹窗；服务端 fight_startgenie 调外部战斗服务成功时只采信 Result.IsWin/Round/Seed，不带双方剩余血量，也不会用本地战斗复核。截图中战斗回放画面我方仍有存活、敌方多数死亡但弹“挑战失败”，符合外部服务判负与本地回放结果不一致。已在服务端对外部战斗服务返回失败的灯神战斗增加本地复核：同一份 battleData 跑本地灯神战斗，若本地判胜则修正 isWin=true，并使用灯神专用 runGenieFallbackBattle 兜底规则，保证服务端发奖/解锁与客户端回放胜负一致。
验证：查看了两张截图、客户端 GenieModule/BattleResultUIComp/UIBattleResultTip 结算路径、服务端 fight_startgenie/geniex.FightStart/buildGenieBattleDataWithResult/runGenieFallbackBattle，以及 2026-05-05 服务端 genie 战斗统计日志；已运行 env GOCACHE=/tmp/go-build go test ./internal/geniex 和 env GOCACHE=/tmp/go-build go test . -run 'TestRunGenieFallbackBattle_UsesBattleSimWinRuleAtRoundLimit' 通过。

问题17：
状态：已修复
现象：怪异塔内 伤害不对 我方武将不可能一次才几千伤害
预期：对怪物的伤害正常
截图：
修复：根因是客户端 EvoTowerModule 通过 evotower_readyfight 返回的 battleData 播放战斗；服务端 HandleReadyFight 构造 leftTeam 时直接使用持久化原始 role.Heroes，没有合入俱乐部科技、装备淬炼、动态战斗加成等。截图里队伍面板战力 151 亿，但战斗血条只显示 3979585HP、普攻只打 7037，符合服务端下发未加成战斗属性。已给 evotower_readyfight 增加专用 GetBattleRole：构建战斗数据时使用 GetroleWithBonus/MergeRoleWithBonus 后的战斗角色；evotower_getinfo/evotower_fight 保存进度仍使用原始角色，避免把动态属性写回持久化数据。
验证：查看了截图、客户端 EvoTowerModule.createBattleInputData/battleEnd、服务端 evotower_readyfight/evotower_fight、buildLeftBattleTeam、buildEvoTowerWSDeps，以及 2026-05-05 服务端 evotower_readyfight/fight 日志；已新增 TestHandleReadyFight_UsesMergedBattleRoleForLeftTeam。已运行 env GOCACHE=/tmp/go-build go test ./domains/activity/evotower 和 env GOCACHE=/tmp/go-build go test ./entry/activity/activityentry 通过。

问题18：
状态：已修复
现象：个人主页内无法关闭切磋 点击关闭无反应
预期：正常关闭开启切磋
截图：
修复：根因是客户端 PlayerInfoDialog 点击“关闭切磋”后调用 SystemService.setSwitch，发送 system_setswitch typ=1 value=false；服务端 system_setswitch 直接对 Mongo 做 $set switches.1。问题角色 202664 的历史数据里 switches 为 null，Mongo 返回 Cannot create field '1' in element {switches: null}，服务端回 code=3/msg=保存失败，客户端刷新后仍认为切磋开关未关闭，所以表现为点击无反应。已在服务端 system_setswitch 读取 switches 父字段：父字段缺失/null/非法类型时初始化为 {"1": false/true}；父字段是正常对象时继续只更新 switches.，避免覆盖已有开关。
验证：查看了截图、客户端 PlayerInfoDialog._onClickCloseDuel/_sendSetPvpSwitch/_isOpenPvp、RankModule 发起切磋路径、服务端 system_setswitch 处理器和字段化 ApplyPatch；服务端日志 2026-05-05T21:36:42 至 21:37:01 多次出现 roleId=202664 CMD=system_setswitch typ=1 value=false 后 ApplyPatch failed: Cannot create field '1' in element {switches: null}。已新增 TestBuildSystemSetSwitchPatch_InitializesNullParent 和 TestBuildSystemSetSwitchPatch_UpdatesExistingParent。已运行 env GOCACHE=/tmp/go-build go test . -run 'TestBuildSystemSetSwitchPatch' 通过。