bug反馈 2026.5.10
问题1：
状态：已修复 验收通过
现象：深海灯神内 每天可以扫荡两次 且点击扫荡显示扫荡卷不足（深海是无法使用扫荡卷的）
预期：深海灯神每周没人只能扫荡一次已通过的最高关卡 且扫荡过后显示的是已扫荡
截图：

问题2：
状态：待验证
现象：咸王梦境内 未选择武将上阵 点击选择武将显示上阵武将以全部死亡 无法正常进行
预期：每次梦境开启首次进入玩家都可以自行选择5个武将上阵
服务端根因：梦境房间运行时只按 2 小时清理，未按当前梦境开启窗口隔离，历史房间的 stage.fightSnapData 可能残留到新一期开启；客户端根据该字段判定当前玩家已打过当前 boss，因此首次进入也会弹“武将已全部死亡”。
修复：服务端在梦境房间恢复、读取、设置出战、开战和定时清理路径统一按当前开启窗口清理过期房间，并在 pve/nightmare 领域层下沉窗口过期判断；已增加过期清理日志 nightmare_room_expired。
验证：已跑 GOCACHE=/tmp/go-build go test ./domains/pve/nightmare；GOCACHE=/tmp/go-build go test . -run Nightmare。待客户端实机复测后再改已修复。
截图：

问题3:
状态：待验证
现象：十殿内 上一关胜利后到下一关 会出现点击玩家上场显示房间不存在
预期：每一关都可以正常选择上阵 正常战斗 不会显示房间不存在
服务端根因：梦境/十殿运行时清理只看房间 CreateAt+2 小时，通关进入下一关时虽然 StateEndTime 会刷新继续当前房间，但 CreateAt 不变，当前期开启窗口内仍有效的房间可能被定时清理，后续 nightmare_setfighter 按 roomId 查不到房间并返回“房间不存在”。
修复：服务端房间过期规则改为跨梦境开启窗口必清理；同一开启窗口内以 StateEndTime 覆盖 CreateAt+2 小时的过期点，避免有效下一关房间被误删；相关读取/恢复/设置出战/开战路径统一调用该规则。
验证：已跑 GOCACHE=/tmp/go-build go test ./domains/pve/nightmare；GOCACHE=/tmp/go-build go test . -run Nightmare。待客户端实机复测后再改已修复。
截图：

问题4：
状态：已修复 验收通过
现象：鱼灵璇玑在升级时一星升级二星会一次扣除两个一星璇玑
预期：所有鱼灵升级一星应只扣除一星
截图：

问题5：
状态：待验证 验收通过
现象：玩家武将赐福后 主页赐福显示会显示+5以上 且现在赐福不是每个部位随机一条
预期：最大消失为+5 根据主线战斗赐福数量判定 赐福4个部位每个部位最多随机赐福一条到武将 注：1. 标识含义：“+”代表4个部位都被赐福，数字取4件赐福装备的最低红词条数（如武器5红、头盔5红、铠甲5红、战马5红，即+5；若战马3红则为+3），+5是最高等级，代表献祭装备均满红。
服务端根因：资料页/主页展示用的 heroEBuffMap 由服务端 BuildHeroEBuffMap 生成，旧逻辑把上阵武将已赐福部位的源装备红词条数累加，4 件满红会算成 20；客户端只是展示服务端下发值，所以出现 +20、+10 等超过 +5 的显示。
修复：服务端 heroEBuffMap 改为只在当前主线上阵武将 4 个部位都存在有效赐福时显示，数值取 4 件赐福源装备红词条数最小值并封顶 5；战斗赐福生效逻辑仍保持每部位最多随机一条。
验证：已跑 GOCACHE=/tmp/go-build go test ./internal/gameplay/enchantx；GOCACHE=/tmp/go-build go test ./internal/gameplay/rankx。待客户端实机复测后再改已修复。
截图：

问题6：
状态：待验证 验收不通过
现象：深海灯神内第三关 boss伤害不对 每次只能造成1点伤害 且赢了判定输
预期：伤害正常 赢了就是赢了
服务端日志：截图战斗 ID 1778485107395 对应 server/logs/2026-05-11/app-140209-175107.log，15:38:27 服务端加载 genieId=5003，外部战斗服务返回 isWin=false、round=5、totalFrame=2617；同一请求协议 trace_id=493593-test53XSCU9V-189-fight_startgenie 正常返回。
服务端根因：fight_startgenie 只采信外部战斗服务的 minimalResult 胜负；外部服务返回失败时，本地回退/客户端同源战斗结果没有参与复核，导致客户端回放看起来已赢但服务端仍按外部 isWin=false 结算。深海 5003 的 1 点伤害仍需要下一次复现日志确认具体是护甲/格挡/攻防哪一项触发，因此本次增加了深海失败聚合审计日志。
修复：服务端在外部战斗服务返回失败时，使用同一份 battleData 跑本地回退战斗复核；若本地判定胜利，则修正 battleData.result.isWin 和顶层 isWin，保证“赢了就是赢”。同时对深海灯神失败记录 battleId、genieId、左右队攻击/血量/防御/右队数量，继续定位 1 点伤害根因。
验证：已跑 GOCACHE=/tmp/go-build go test ./internal/geniex；GOCACHE=/tmp/go-build go test . -run Genie。待客户端实机复测后再改已修复。
截图：

问题7：
状态：待验证 验收通过
现象：咸王挑战内挑战获得的奖励不对 且每打一次的伤害都会叠加到最高伤害
预期：应获得所显示奖励每个阶段的总和 总高伤害应该是显示最高的一次 而不是一直叠加
服务端根因：咸王挑战战斗结算 FightStartBossFieldized 把 TotalDamage += currentDamage 当成进度，boss_getstate/排行榜/奖励领取也读取 totalDamage，导致每打一次都会把本次伤害累加到“最高伤害”。阶段奖励同样按累计前后跨档发放，和客户端面板按最高单次伤害档位展示不一致。
修复：服务端将咸王挑战进度口径改回单次最高伤害：战斗写入使用 max(历史最高, 本次伤害)，奖励只按最高伤害新跨过的阶段补发；boss_getstate、排行榜、奖励领取优先使用 MaxSingleDamage，并在领取时归一已有累计脏值，避免历史错误继续影响展示/领取。
验证：已跑 GOCACHE=/tmp/go-build go test ./internal/gameplay/bosschallengex；GOCACHE=/tmp/go-build go test ./domains/pve/boss ./internal/bosschallengeentry；GOCACHE=/tmp/go-build go test . -run Boss。待客户端实机复测后再改已修复。
截图：

问题8：
状态：待排查 不通过
现象：怪异塔怪异寻宝内怪物拉倒相邻的位置会一直分化 退出游戏在进入后会消失
预期：拉到相邻的位置不会分化
客户端链路：MergePlayTilesContainer._tryApplyItemDrop 在拖拽到同道具格时会先调用 MPData.canMergeItems 并本地乐观合成，再发 mergebox_mergeitem；MPData.sendMergeItems 在服务端返回非 0 时会调用 _withdrawChanges 按当前 mergeBox.gridMap 回滚。因此“退出再进后消失”不能单独证明服务端已经持久化了相邻合成结果。
服务端日志：2026-05-11 服务端 protocol 日志中可见测试账号在怪异寻宝内连续发送 mergebox_getinfo、mergebox_openbox、mergebox_mergeitem、mergebox_moveitem，例如 roleId=842359/testNCD9XKGZ 在 19:47:21 起多次 mergebox_mergeitem，roleId=345320/testHRBSEBS8 在 16:58:31 起多次 mergebox_mergeitem；但历史 protocol 日志只有协议名、耗时、包大小和 sendOk，没有 sourcePos/targetPos 和业务 code，不能直接证明截图这次相邻拖拽被服务端成功接受。
服务端根因/风险点：server/domains/activity/mergebox/compat.go 的 HandleMergeItem 旧逻辑只校验源/目标都是相同 gridType=2 道具且存在 NextLevelMergeItem，没有服务端相邻格拒绝规则；如果客户端发出相邻同道具合成请求，旧服务端会按合法合成处理。这是服务端规则缺口，但截图对应的历史请求因日志字段不足仍需复现确认。
修复/排查：服务端在 HandleMergeItem 下沉增加相邻格（含斜向相邻和同格）拒绝逻辑；同时增加低频诊断日志 mergebox_mergeitem_reject_neighbor，记录 roleId、actType、source/target 坐标和源/目标道具，后续复现可直接确认是否命中服务端拒绝。客户端未改动。
验证：已跑 GOCACHE=/tmp/go-build go test ./domains/activity/mergebox、GOCACHE=/tmp/go-build go test ./entry/activity/activityentry。待带诊断日志实机复现后，再根据日志把状态改为待验证或继续定位。
截图：

问题9：
状态：待验证 验收通过
现象：主页珍宝阁珍宝换购内 不能正常换购东西 显示为空 且不扣资源
预期：可以使用资源正常购买 且到账
客户端链路：珍宝阁入口进入 ActCollectionShopShop，列表通过 CollectionService.goodsList 读取 storeInfo.exchangeStoreMap，点击兑换后调用 ActCollectionShopModule.exchangeGoods，实际协议为 CollectionService.exchange({goodsId, goodsNum}) / collection_exchange。
服务端日志：2026-05-11/2026-05-12 protocol 日志里大量 collection_goodslist 正常返回，例如 2026-05-11 19:12 roleId=842359 collection_goodslist、2026-05-12 01:37 roleId=70442 collection_goodslist/collection_claimfreereward，但没有可用的 collection_exchange 处理记录；结合服务端注册表确认兑换协议未注册，客户端点击兑换不会进入服务端扣资源/发货逻辑。
服务端根因：entry/account/wsentry 只注册了 collection_goodslist、collection_claimfreereward、排行等协议，缺少客户端实际调用的 collection_exchange；服务端也没有珍宝换购的扣除 CollectionGiftPackConstant.exchangeItemId=70001、写入 exchangeStoreMap、发放 CollectionExchangeShopConf 奖励的处理链路。
修复：新增 server/internal/activityx/collection_shop.go 下沉珍宝换购逻辑，按 CollectionExchangeShopConf 校验商品/限购/消耗，扣除 70001，发放道具奖励并更新 exchangeStoreMap；根 WS 入口只新增薄 handler 和协议注册 collection_exchange。
验证：已跑 GOCACHE=/tmp/go-build go test ./internal/activityx、GOCACHE=/tmp/go-build go test ./entry/account/wsentry、GOCACHE=/tmp/go-build go test . -run Collection。待客户端实机复测后再改已修复。
截图：

问题10：
状态：待验证 验收通过
现象 ：无法正常申请俱乐部 点击申请俱乐部无反应
预期：可以正常申请每个俱乐部
截图：

问题11：
状态：待验证 验收通过
现象：金鱼升级星级后图鉴内金鱼图鉴不能升星
预期：图鉴内每个金鱼星级更具玩家背包内金鱼星级实时更新
截图：

问题12：
状态：待验证 验收通过
现象：四圣突破等级时用连点器一直点击就会跳等级
预期：永远只能一级一级升级
截图：

问题13：
状态：待验证 验收通过
现象：招募内 抽奖一次后 招募令从3000变成负数了
预期：招募消耗扣除多少招募令 最低为0 不会有负数
客户端链路：招募面板 HeroRecruitDialog._refreshRecruitTen 读取 ROLE.getItemQuantity(ConstantConf.config.recruitTicketId) 刷新十连按钮；点击十连通过 RecruitModule.trySendRecruitTenHero(10) 调用 HeroService.recruit({recruitNumber:10,recruitType:ticket})，客户端只合并服务端 role/items 回包，不自行扣招募令。
服务端日志：2026-05-12 11:30:58 roleId=666754/testX7K2GQGA 的 hero_recruit trace 666754-testX7K2GQGA-1586-hero_recruit 解析为 recruitNumber=10 recruitType=1 byClub=false 并成功返回；数据库核对该角色当前 items.1001.quantity=45，说明服务端落库不是负数，异常来自服务端回包给客户端的道具剩余数计算。
服务端根因：server/internal/gameplay/herox/recruit_fieldized.go 十连扣除 items.1001.quantity -= 10 后，构造 role.items 回包时没有把消耗道具 items.1001.quantity 加入二次读取路径，导致旧数量按 0 参与计算；旧回包会出现 0-10=-10，当前虽然已有非负兜底但仍会错误回 0，客户端合并后显示不对。
修复：服务端在招募领域逻辑里把所有 itemDeltas（含招募令 1001）加入回包前读取路径，回包按真实旧数量加 delta 得到正确剩余；同时 statistics.today:recruit 改为按实际招募次数累加，十连 +10。
验证：已跑 GOCACHE=/tmp/go-build go test ./internal/gameplay/herox -run 'Recruit'、GOCACHE=/tmp/go-build go test ./internal/gameplay/herox。新增十连回归测试覆盖 55 个招募令十连后回包和落库均为 45。
截图：

问题14：
状态：待验证 验收通过
现象：俱乐部内队员状态永远是在线
预期：正确显示队员在线离线状态
截图：

问题15：
状态：待验证 验收通过
现象：盐场内战力会随着精力变化而变化
预期：当前上阵战力多少就是多少 不会根据精力而变化
截图：

问题16：
状态：待验证 验收通过
现象:玩家死亡后 等免费的复活 精力不会恢复到100 而是死亡前的精力
预期：不管是免费次数复活还是复活丹复活 复活后精力都会恢复到满100状态
截图：

问题17：
状态：已修复 验收通过
现象：盐场战报内攻击方防守方显示不对
预期：例如玩家1和玩家2 1主动挑战2 那么1就是攻击方2是防守方 反之亦然
根因：服务端 domains/legion/read/details.go 构造盐场 targetRoleList 时把双方 attackType 都固定为 0（attack），客户端 LegionWarReportDetailDialog 按该字段显示攻击方/防守方并映射回放双方，导致防守方视角也被标成攻击方。
修复：服务端按战斗 leftId/rightId 生成 attackType，发起者返回 0（attack），防守方返回 1（defense），并补充回归测试 TestBuildDetails_AttackTypeMatchesBattleSide。
验证：已查看问题描述、截图、客户端 LegionWarReportDetailDialog.js/LegionWarBattleDetailsDialog.js、服务端盐场开战与战报明细代码、server/logs/2026-05-11/saltfield.log；执行 GOCACHE=/tmp/go-build go test ./domains/legion/read -run 'TestBuildDetails_AttackTypeMatchesBattleSide|TestBuildDetails' 通过。
截图：

问题18:
状态：已修复 验收通过
现象：盐场内一个热可以同时开战多个敌人
预期：一个人一次只能和一个敌人对战 对战结束后才可以去挑战其他人或者被挑战
截图：

问题19：
状态：已修复 验收不通过
现象：玩具更换后 玩具加成属性在武将身上不会立马变换 需要退出游戏再进才会变
预期：玩具刚换后属性变化立马体现在武将身上
根因：服务端 lordweapon_changedefaultweapon 写入 lordWeaponId 后立即重算回包英雄属性，但重算依赖的最小 Role 视图可能仍读到旧 LordWeaponId（字段缓存/读视图滞后），导致本次回包的 role.heroes 仍按旧玩具加成计算；重登后全量读库才会显示正确。
修复：internal/gameplay/lordweaponx 在换玩具成功后，强制把本次请求的 weaponId 写入重算用 Role 视图；power 以权威 RefreshMainPower 结果为准并传入本次 updatedAtNs 输入版本，局部 bonus 只作为失败 fallback 和上阵英雄 heroes 属性回包来源，避免旧视图参与动态加成计算。
验证：已查看问题描述、三张截图、客户端 WeaponTeamEquipDialog.js/WeaponModule.js/HeroTeamPanel.js、服务端 lordweapon_changedefaultweapon handler 与 LordweaponChangeDefaultFieldized、server/logs/2026-05-11/protocol.log 中同类换玩具请求；执行 GOCACHE=/tmp/go-build go test ./internal/gameplay/lordweaponx -run 'TestLordweaponChangeDefaultFieldized_RecalculatesWithRequestedWeapon|TestLordweapon' 通过，覆盖权威战力优先和新玩具视图重算。
截图：

问题20：
状态：未处理
现象：盐场内玩家精力掉到1精力后 不影响实际血量和攻击
预期：显示的战力不会掉 但是实际血量攻击等会随着精力减少而变化（精力减1 攻击血量也会减少百分之1 ）
具体规则：玩家初始拥有 100 点精力值，每次与其他玩家战斗会消耗 5 点精力值，耗时 10 秒，攻打一次建筑物会消耗 1 点精力值，耗时 5 秒，精力值降低会同比例降低武将的攻击力与血量最大值
截图：

问题21：
状态：未处理
现象：大本营被占领后显示的界面不对 有的号回显示复活倒计时
预期：大本营被占领后界面显示正常
截图：