Bug 反馈 2026.5.20 ¶

盐场生产 panic 根治补充（2026-05-30）：
状态：服务端已修复，待测试服/生产回归验证。
根因：同一盐场 battlefield snapshot 内，handler、timer、归档/查询路径并发读写 live map；多轮点状修复后仍有 war_getbattlefieldinfo、手动 war_resurrect、scheduleAutoRevive 等入口绕过统一 snapshot 锁/副本边界，触发 Go runtime concurrent map iteration/read and map write。本次按单战场 snapshot.mu 根治：锁内只做内存校验、mutation、递归 copy 和 delta 构造；锁外发送、广播、落库和外部依赖；异步 timer/goroutine 按 battlefieldId 重新解析当前 live snapshot。补充死锁审计：已修复手动复活锁内调用 moveRoleToHome、ResetRoleTeamCurHp 的自锁风险，以及 war_kickoutteam 锁内 applySelfFields 重入和锁内发包/广播风险。验证：go test -race . -run 'TestBattlefieldInfoPayloadSnapshotCopy_ConcurrentWriterSafe|TestWarResurrectConcurrentWithApplyBattleTeamUpdateSafe|TestScheduleAutoReviveInitialSchedule_ConcurrentWriterSafe|TestWarKickOutTeam_DoesNotReenterSnapshotLockWhileWriterWaiting'、go test -race ./internal/saltfieldpanic 通过；生产栈已分别映射到战场信息 copy、手动复活 copy、自动复活调度三条路径。

问题2：
状态：验收通过（服务端已修复 collection_exchange 回包 role/roleInfo 增量，购买后下发耀晶徽记扣减）
现象：珍宝阁购买物品后 不会立即显示扣除对应耀晶徽记 需要退出游戏再进才会显示扣除
预期：购买东西后立马扣除所需耀晶徽记
截图：

问题3：
状态：验收通过（服务端已修复珍宝阁兑换皮肤/头像框/背景奖励落库，避免已购买外观仍按未拥有展示）
现象：吕布和周瑜皮肤购买后退出再进会继续显示为可购买状态 可以重复购买
预期：购买一次后就显示为已售空 不可以多次购买
截图：

问题4：
状态：验收通过（服务端已将 type=11 皮肤奖励写入 hero.skin/useSkin 并随 role 增量返回）
现象：皮肤购买成功后 武将皮肤栏里未点亮 为未拥有状态 无法佩戴
预期：购买后 武将皮肤栏点亮 可以正常佩戴
截图：

问题5：
状态：服务端已修复，验收通过（复核于 2026-05-22。账号 fafa，问题原 ID:390697，另按要求复核 151830。已看截图 image-2026-05-20T13-10-23-864Z / 13-10-27-481Z / 13-10-30-983Z、客户端 CollectionThemeSuitsDialog/CollectionModule/CollectionData/RoleDataView、服务端 collection_exchange/collection_getinfo/collection_claimseries/zhurenlv 奖励计算代码、2026-05-20/21/22 服务端日志和 Mongo 数据。根因一：兑换皮肤/头像框/背景只落拥有数据，未同步写 collectionActivated，客户端套装页读取 suitSeries.collectMap.activateNum，买齐后仍灰且无可领奖励；根因二：内置 CollectionHeroSuitsConf 将武将皮肤放在 items type=1，但 buildCollectionThemeSeries 的 items 分支只按装饰 collectionOwnsDeco 判断，type=1 皮肤不计入套装进度；根因三：CollectionHeroSuitsConf.stageAttrReward 领取后只保存 CollectionHeroSuitClaim 和发道具，Getrole/BonusCalculator 未把已领取套装档位的 attack/hp/技能伤害等加到对应 heroId，collection_getinfo 的 suitSeries.addAttrMap 为空。已改为兑换 type 11/46/50 时自动写 1/6/8 对应 collectionActivated 并回包增量；套装 items 的 type=1 按皮肤拥有/激活判断；按 CollectionHeroSuitClaim + 实际收集进度计算已领取套装加成，写入对应武将攻击/血量百分比和特殊属性，并返回 suitSeries.addAttrMap；补 activatedKeys 日志。今日 Mongo 确认 151830 和 390697 的 10503/10702 两套均 skin/frame/map owned=true、skinAct/frameAct/mapAct=1、claim=3；Docker 17:30 后 151830 没有新的 collection_* 请求，但 fight_startlevel 战斗包已带套装属性 61:0.2 且攻击/血量已生效。验证：go test ./internal/activityx、go test ./internal/gameplay/enchantx、go test . -run 'TestBuildCollectionInfo|TestCollection|TestCalculateHeroBonus_AppliesClaimedCollectionSuitBonus|TestCollectionClaimedSuitBonuses_AppliesClaimedHeroSuitStages'，以及 2026-05-22 复跑 GOCACHE=/tmp/go-build go test . -run 'TestBuildCollectionInfo|TestCollectionClaimedSuitBonuses_AppliesClaimedHeroSuitStages|TestCalculateHeroBonus_AppliesClaimedCollectionSuitBonus|TestCollectionStageFlatBonus' 通过）
现象：购买皮肤和背景后 珍宝阁内无法点亮三件套 不会三个一起亮 随机亮起两个 激活加成显示没有奖励可以领取
预期：成功购买后可以正常点亮三件套 并且获取对应加成到对应武将身上
截图：

问题6：
状态：服务端已修复，验收通过（facai122 日志确认次数已重置；新根因为客户端 claimedStageIdMap 是增量 Map，服务端重置时回 {} 不会删除各层级已领取标记。已改为重置回包对所有累计奖励层级下发 null 删除标记）
备注：现在重置次数 但是达到次数后显示奖励已领取 不能再次领取奖励
现象：宠物扭蛋抽奖100次后 不会重置刷新
预期：100次后会重置刷新 重复领取奖励
截图：

问题7：
状态：服务端已修复，验收通过（复测 2026-05-24 下午日志确认问题复发根因仍是合成响应缺少客户端增量 Map 删除标记；之前为降低宠物响应包只保留结果槽位时把 top-level role/roleInfo 的 fromSlot:null 裁掉，导致客户端旧格子不删除。已恢复 pet_merge 在 role/roleInfo/rawData.role/rawData.roleInfo 的 petData.pets[fromSlot] 下发 null 删除标记，同时只保留 fromSlot/toSlot 两个相关槽位避免全量宠物包过大。验证：GOCACHE=/tmp/go-build go test ./domains/pet）
备注：合成后高等级宠物后 原来的宠物依然会不会消失
现象：宠物合成内 两个宠物合成后 有一个宠物不会消失 需退出游戏再进才会消失
预期：合成说明

1. 2只相同品质的宠物可拖动到一起进行合成，最高品质宠物不可继续合成。
   2.合成成功时，可获得 1 只高一级品质的随机宠物。
   3.紫色品质及以上的宠物进行合成时，阿咸大大可先选择其中 1 只宠物作为继承对象；合成成功后，新宠物将继承所选宠物的等级与精炼，另一只宠物消失，并按规则返还部分升级道具与精炼道具。
   4.紫色品质以下的宠物进行合成时，将优先继承等级经验更高的宠物；若双方相同，则随机继承，不可手动选择。
   5.合成失败时，将保留已选择或按规则继承的宠物，另一只宠物消失，并返还 100% 成长脆饼与 50% 幻彩灵果。
   6.已上锁的宠物无法参与合成。
   截图：
   
   

问题8：
状态：服务端已修复，验收通过（已看截图、客户端 PetModule/PetMergeSelectDialog/PetHomeDialog、服务端 pet_merge 代码和 2026-05-21 facai122 服务端日志；04:00:30 日志确认客户端继承/预览的是 keepPetId=403 铁头飞猪，但服务端成功合成时随机到 resultPetId=504 灰烬兔。根因为成功合成目标没有按继承宠物 series 同系进阶。已改为成功合成时优先按保留宠物 series 选择下一品质同系宠物，找不到同系配置才回退随机池，并新增 targetMode/keepPetId/dropPetId/resultPetId 日志；后续 04:05:04/04:05:08 日志已有 targetMode=series 且 403->503、503->603；go test ./domains/pet 通过）
现象：合成成功显示的宠物和实际到账的宠物不一样
预期：合成成功显示是什么实际就是什么
截图：

问题9：
状态：服务端已修复，验收通过（5-20 账号 123456、5-21 账号 facai122 均未查到 pet_quench/pet_quenchconfirm 服务端请求；已增加服务端精炼拒绝/成功日志，待客户端复测点击精炼是否正常发起请求并出现词条）
现象：宠物点击精炼无反应
预期：点击精炼可以正常淬炼 出现词条
截图：

问题10：
状态：已修复 验收通过（facai122 2026-05-21 03:12:53 pet_swap 日志确认服务端已将 slot1=9 清空并移动到 slot2=13；根因为客户端 PetRoleDataView 对 pets 按增量 Map 合并，服务端回包缺失 slot1 不会删除原位置。已改为 pet_swap 移动到空格时在 role/roleInfo/rawData.role/rawData.roleInfo 的 petData.pets[源槽] 下发 null 删除标记，DB 持久化仍保存真实清理后的 petData）
现象：移动宠物到空位置会分化出一个同样的宠物 需要退出游戏再进才会消失
预期：移动宠物位置不会分化
截图：

问题11：
状态：已修复 验收通过（已看截图、客户端 PetConf/PetDataView/PetConstData 和 facai122 2026-05-21 03:18/03:26 服务端日志；根因为 pet_useexpitem 一键升级只改 level/exp/skill，后续修复又误把 attrBasicValue 当每级成长直接乘等级，导致 603 宠物 69 级 hp=2760000000 超过客户端 32 位数值边界后显示负数。已改为使用配置 attrBasicGrowValue，公式为基础值 + 成长值 * (等级-1)，同步同 uId 的所有宠物副本，并保留 attrBasic=1/3 时将 3 兼容为 HP；新增 pet_useexpitem 升级前后属性日志）
现象：宠物攻击血量不对 血量为0 升级后也不会变化
预期：每个宠物攻击血量正确且每次升级都会有对应提升
截图：

问题12：
状态：服务端已修复，验收通过（已看截图、客户端 PetModule/PetHomeDialog/PetRoleDataView、服务端 pet_load 代码和 2026-05-21 pet_load 日志；根因和问题10同属宠物残留/分化，但触发链路是 pet_load 上阵：服务端原逻辑把宠物复制到 -1 上阵位，原格子仍保留同 UID，回包也没有 null 删除标记，导致客户端增量 Map 合并后布阵选择里出现两个使用中宠物。已改为 pet_load 在上阵台和格子间按移动/交换处理，并对被清空的 -1 或原格子下发 null 删除标记，同时清理历史同 UID 残留；go test ./domains/pet 通过）
现象：宠物挪动到上面去之后 格子里还有这个宠物 以至于布阵切换宠物页面显示两个宠物
预期：宠物合成页面 宠物挪动到上面台子上之后 下面格子不显示这个宠物
截图：

问题13：
状态：服务端已修复，验收通过（已看截图 image-2026-05-21T08-15-26-848Z.png / image-2026-05-21T08-15-31-315Z.png、客户端 DungeonPanel/DungeonShopPanel/DungeonJuniorShopPage/DungeonModule/协议 Dungeon_BuyMerchant，服务端 dungeon_buymerchant/dungeon_skipmerchant/domains/pve/dungeon 代码和 2026-05-21 服务端日志；日志中 fafa1 16:12:03 起多次 dungeon_buymerchant 返回 code=3“商人驿站未开启”，前序 16:11:55 dungeon_skipmerchant 已把 currMerchantId 置 0。根因为服务端跳过商人只清 currMerchantId，没有清 dungeon.merchant[商人ID]，而客户端商店页 isUnlockMerchant 只按 ROLE.dungeon.merchant 是否还有商品列表判断，导致旧商人商品残留，点击购买后服务端按 currMerchantId=0 拒绝，看起来像购买无反应。已改为 skipMerchant 同时 unset 当前 merchant 列表并在回包下发 merchant[商人ID]=null 删除标记，客户端增量合并会移除旧商品；dungeon_buymerchant 已补成功/拒绝日志；go test ./domains/pve/dungeon、go test . -run 'Test.*Dungeon|TestResolveDungeon|TestBuildDungeon' 通过）
现象：咸王梦境内商人驿站开启后里面物品点击后买无反应 无法正常购买
预期：可以正常购买所有商品
截图：

问题14：
状态：服务端已修复，验收通过（已看截图、客户端 ResidentGachaData/ResidentGachaRewardDialog/ResidentGachaPage、服务端 gacha_claimstagereward 逻辑和 2026-05-21 日志；根因为领取完最后一档累计奖励后服务端将 stageGachaCnt 直接置 0，facai122/fafa1 日志均出现 stageGachaCnt=110/105/120 后 reset 到 0，导致超过 100 的溢出次数丢失。已改为全档领取重置时保留 stageGachaCnt - 最大累计档位，刚好 100 保留 0，110 保留 10，同时继续下发 claimedStageIdMap 的 null 删除标记刷新新一轮奖励；go test ./domains/gacha 通过）
现象：宠物扭蛋抽奖时 次数大于100次时 领取完100次奖励后 溢出的次数会清空 不会继承到下一轮
预期：溢出的次数会继承到下一轮
截图：

问题15：
状态：服务端已修复，验收通过（2026-05-22：已看描述/截图/客户端协议/服务端协议/容器日志。客户端 LegionSettingDialog 中公告提交走 legion_editannouncement，无需审核走 legion_editinfo；服务端只注册了 legion_editname，缺少这两个命令的注册和 handler，同时 legion_getinfo 返回的 info.noApply 固定为 false，导致刷新后勾选状态无法保持。账号 123456 容器日志确认 roleId=243239，15:20 附近只有 legion_getinfo，返回公告为 tttt 且没有正常的 legion_editannouncement/legion_editinfo 处理日志。已补服务端 legion_editannouncement/legion_editinfo 注册、持久化、返回字段和诊断日志，并将 getinfo 的 noApply 改为俱乐部真实值。验证：GOCACHE=/tmp/go-build go test ./domains/legion/member、./domains/legion/read、./entry/account/wsentry、go test . -run '^$' 通过；根包 Test.*Legion 触发既有盐场/航海时间窗用例失败，非本次改动。）
现象：俱乐部内勾选无需审核无反应 俱乐部公告点击更改确认后无变化 无法更改
预期：可以正常勾选或者取消勾选无需审核 团长副团长可以正常更改公告
截图：

问题16：
状态：待复现（先不修复；已看描述/截图/客户端协议/服务端源码和 2026-05-22 服务端日志。截图提示对应服务端 nightmare_fight 调 battle worker 失败分支；客户端相关协议为 nightmare_setfighter / nightmare_fight。落盘日志 2026-05-22 04:25-04:35 未查到对应 nightmare_* 协议链路，今天日志也未查到可定根因请求，等复现后用新 trace 再排查。）
现象：十殿内 点击选择玩家出战一直显示战斗服务繁忙 无法正常上场出战
预期：选择玩家出战后可以正常上场战斗
截图：

问题17：
账号：fafa 密码：123456 ID:151830
状态：服务端已修复，验收通过（已看截图、客户端 RoomScene/HeroTeamPanel/SpecificsTeamDialog/RoleDataView/PetEquipDialog/PetModule、服务端 pet_load/savePetData/zhandouli/BonusCalculator 代码、2026-05-22 Docker 服务端新日志和 Mongo 数据；账号 123456 当前 roleId=243239 库内无宠物，16:30-16:40 Docker 日志只有 fight_startlevel 且 petId=0/petUId=""，未触发 pet_load，账号 fafa/151830 日志可见宠物进战斗。二次根因：前次只修了 BonusCalculator 总战力补宠物，但宠物 savePetData 仍用 zhandouli(role) 直接写回 power；该 role 是未套完整动态加成的原始角色视图，且 zhandouli 遇到 hero.Power 会直接用旧值，导致换宠物时可能把 power 写成“旧/原始英雄战力 + 宠物战力”，客户端主线只读 ROLE.power，所以会显示异常，直到布阵等操作重新走完整加成才恢复。已改为宠物变更保存时用 GetroleBonusWithOriginalRole/BonusCalculator 完整口径计算并写回 power，补 pet_power_resolve 日志；pet_load 成功后额外推 syncresp.roleInfo，让主线战力和武将面板立即刷新。验证：GOCACHE=/tmp/go-build go test . -run 'TestResolvePetMutationPowerUsesCalculatedHeroPower|TestBonusCalculatorCalculateTotalPowerAddsEquippedPetPower'、go test ./domains/pet、go test . -run 'TestHandleLoad|TestResolvePetMutationPowerUsesCalculatedHeroPower|TestBonusCalculatorCalculateTotalPowerAddsEquippedPetPower' 通过）
现象：进了宠物系统后 或者换宠物后 主线只显示宠物的战力 不正常显示当前的正确战力 需要去动一下武将布阵等东西才会恢复正常战力 且宠物的战力不加在总战力内 加成不上武将面板
预期：当前战力正常显示为当前阵容+宠物达到所有战力总和 不会出现只显示宠物战力的情况 宠物战力正常加在总战力内 加成计入武将面板
截图：

问题18：
账号：fafa 密码：123456 ID:151830 时间2026.5.22 17:03
状态：待复现（已看截图 image-2026-05-22T05-06-31-749Z / 05-06-35-606Z / 05-06-39-660Z / 05-06-44-322Z，截图显示四圣转换后目标武将阶数已到奖励档位，但盐场飞毯/头像框/个性名片等外观仍为未解锁；已看客户端 HolyBeastSkinModule/HBExchangeDialog/HBDressGetDialog/PlayerInfoDialog 和协议 HB_Exchange=hb_exchange、Role_LoadDress=role_loaddress，客户端转换成功后依赖服务端返回/同步 role.heroes.hB 与全局 role.dress/avatarFrame/profileCard/airshipId 等字段；已看服务端 hbx.Exchange、hbx.UpgradeOrderLegacy/buildUpgradeRewards、hbrewards.FourSaintHBRewardsByHero，升级阶数路径会发放外观奖励，转换路径只交换 hB 和扣道具，疑似转换后未补发目标武将已达档位外观奖励；但 2026-05-22 本地结构化服务端日志 protocol/security/app 未查到 hb_exchange 或账号 123456/roleId 243239 对应四圣转换链路，Docker 日志查询被中断，暂不能用服务端日志定死本次复现请求，先按要求标记待复现。下次复现请提供 hb_exchange trace_id 或账号+准确时间窗）
现象：使用四圣转换后 转换后的武将相应四圣等级的头像框 飞艇等没有解锁
预期：四圣转换后 达到相应等级 正常解锁对应奖励
截图：

问题19：
状态：服务端已修复，验收通过（已看截图 image-2026-05-22T05-23-43-765Z.png，右上角 28991|26501|dev|28 不作为角色 ID；已看客户端 PetInfoQuenchDrawer/PetModule/PetDataView/PetConstData、协议 PetQuench/Pet_LockQuenchResp/Pet_QuenchResp，服务端 pet_lockquench/pet_quench 入口、domains/pet、petprob、rolepetx 以及 2026-05-21/2026-05-22 服务端日志。日志中 5-22 当天和 5-21 facai122 相关窗口均未查到 pet_quench/pet_lockquench/pet_quenchconfirm 请求，无法证明“点击锁定无反应”已到服务端；已在 pet_lockquench 成功、无效槽位、槽位未激活、锁定上限、保存失败补窄日志，方便下次复现定死。词条根因已定：server/config/pet_prob.json 原来品质概率白绿蓝紫橙红均为 1:1，附加属性池只有 1/2/3，且每槽只生成 1 条；与备注的品质概率、1_{2 附加词条、单属性最多 2 次不一致。另 rolepetx 对 attrId=2/3 的解释与客户端 BattleAttributeKey 相反，导致服务端宠物属性/战力计算防御和血量错位。已改为备注概率，附加属性池扩展到面板/功能/职业抵御类百分比属性，支持 1}2 条且同宠同属性最多 2 次；修正 attrId=2 防御、3 血量；go test ./domains/pet、go test ./internal/gameplay/petprob、go test ./internal/rolepetx 通过）
现象：宠物精炼词条属性不对 且点击锁定无反应 无法锁定
预期：词条正确 可以正常锁定
一、精炼开启与基础规则
开启条件：紫色及以上品质宠物，达到指定等级（通常为 50 级）后，可开启精炼功能。
消耗道具：幻彩灵果，用于随机刷新宠物精炼槽位的属性。
槽位上限（按品质）：
表格
宠物品质 槽位上限 可锁定槽位上限
紫色 4 1
橙色 4 2
红色 6 4
金色 8 6
槽位品质与概率：槽位分为白、绿、蓝、紫、橙、红 6 种，品质越高属性越好，出现概率如下：
白：64.7%
绿：20.0%
蓝：11.0%
紫：2.60%
橙：1.30%
红：0.40%
刷新规则：每次精炼时，所有未锁定的槽位都会重新随机；初始所有槽位均未激活，精炼后才会开启。
生效条件：精炼属性仅在宠物上阵后，才会对所有上阵咸将生效。
等级异常处理：若宠物等级不再满足精炼开启条件，已获得的精炼属性会保留但暂不生效，重新达到等级前无法继续精炼或锁定。
附加属性限制：单个槽位内附加属性不会重复；单只宠物同一种附加属性最多出现 2 次，达到上限后不会再刷新出该属性。
合成返还：宠物合成后，会根据原有精炼槽位数量与品质，按规则返还部分精炼道具。
🔒 二、精炼锁定说明
锁定效果：锁定后的槽位在后续精炼中不会被替换。
消耗变化：锁定槽位后，每次精炼的道具消耗会根据锁定槽位的品质与数量增加。
锁定限制：锁定槽位数量不能等于当前槽位总数，也不能超过该宠物可锁定槽位的上限。
⚔️ 三、精炼属性说明

1. 基础词条（固定）
   每个槽位固定拥有 1 条基础属性，统一为血量，最大加成：20000000。
2. 附加词条（12 条 / 槽位）
   每个槽位会随机附带 12 条附加属性，单种附加属性在单只宠物上最多出现 2 次，部分关键属性上限如下：
   职业伤害抵御：抵御战士 / 法师 / 射手 / 刺客 / 辅助 / 肉盾伤害，最大 3%
   功能属性：治疗增强最大 6%、怒气速率最大 6%、技能伤害最大 5%、技能减伤最大 5%、速度最大 5%、免控最大 5%、控制命中最大 5%
   面板属性：血量最大 2.5%、攻击最大 2.5%、防御最大 2.5%
   截图：

问题20：
状态：服务端已修复，验收通过（已看截图 image-2026-05-22T06-34-23-210Z / 06-34-28-791Z / 06-34-34-036Z，客户端 ArenaBattleDialog/DungeonPanel/system-head-board/协议 Fight_StartAreaArena 与 Fight_StartDungeon，服务端 fight_startareaarena/buildPlayerTeam、dungeonx.FightStartDungeonFieldized、enchantx.ApplyBattleBlessings，以及 2026-05-21/2026-05-22 服务端日志。根因：竞技场 fight_startareaarena 手写 leftTeam/rightTeam，未调用 ApplyBattleBlessings，所以战斗 actor 缺 enchantMap 且属性未加成；补充审计发现字段化梦境 fight_startdungeon 也手写单武将队伍且未读取 enchantMap/赐福来源武将，同样漏。已补竞技场双方队伍赐福注入与命中日志，梦境字段化战斗补读 enchantMap 和来源武将后注入赐福；已确认主线、普通 PVP/争霸、PK 房、货运、单体 Boss、Boss 塔、爬塔、进化塔、精灵、军团 Boss、盐场实际 PVP 均走 buildLeftTeam 或专用 ApplyBattleBlessings，未发现同类漏点。验证：GOCACHE=/tmp/go-build go test . -run 'TestFightStartAreaArena_BuildPlayerTeamAppliesEquipmentBlessing|TestFightStartAreaArena_BuildPlayerTeamUsesRolePowerForSnapshot'、go test ./internal/gameplay/dungeonx -run 'TestFightStartDungeonFieldized_AppliesEquipmentBlessing|TestFightStartDungeonFieldized_UsesBattleWorkerResult'、go test ./internal/gameplay/enchantx 通过）
现象：赐福在竞技场内不生效 不显示
预期：赐福后在任何战斗内都生效 正常显示
截图：

问题21：
状态：服务端已修复， 验收通过
本轮补修（已看截图、客户端 HeroAttributeToolTip/HeroDataView/RoleDataView/PetModule 同步字段、服务端 pet_quenchconfirm/Getrole/BonusCalculator/rolepetx 代码、2026-05-22 Docker 新日志和角色 151830 日志）。新日志显示 pet_quenchconfirm 成功后 extraPushCount=0，回包只有 petData/pet/items/power；客户端武将面板读取 ROLE.getHeroById(…).attribute，所以不会收到精炼确认后的上阵武将 attribute 更新。随后 fight_startlevel 日志里同一只上阵宠物 601 的确认精炼词条已经进入战斗武将 attribute，说明计算链路正确，漏的是确认精炼后的面板同步。已改为 pet_quenchconfirm 成功后按客户端需要额外推 syncresp.roleInfo 的最小增量：仅包含当前上阵 heroes 的重算结果和 power，不推全量角色；并新增 pet_quenchconfirm result 日志记录确认词条 attrs，方便下次复现定位。验证：go test . -run 'TestBonusCalculatorAppliesEquippedPetQuenchToBattleHeroes|TestResolvePetMutationPowerUsesCalculatedHeroPower|TestBonusCalculatorCalculateTotalPowerAddsEquippedPetPower'、go test ./domains/pet -run 'TestHandleQuench|TestHandleLockQuench' 通过。
现象：宠物精炼词条里有一种词条显示为代码 且精炼词条加成不到武将身上 面板不显示
预期：代码改为正确的中文 词条加成到武将身上 展示在面板
截图：

问题22：
状态：服务端已修复，验收通过
（已看截图、客户端 PetInfoQuenchDrawer/PetModule、服务端 pet_lockquench/pet_quench 代码和 151830 当前 Mongo 数据。根因：精炼后客户端展示的是服务端回包中由 PendingQuenches 覆盖出来的预览词条，但 pet_lockquench 只改正式 Quenches；有待确认精炼结果时点锁定/解锁，服务端改了旧正式词条，回包继续展示未变的 pending，所以看起来没立即变化，下一次精炼才显现。已改为有 PendingQuenches 时锁定/解锁作用于 pending，并且继续按 pending 的锁定数量计算精炼消耗和保留锁定词条；补 pet_lockquench target=pending/confirmed 日志。验证：go test ./domains/pet -run 'TestHandleLockQuench|TestHandleQuench' 通过）
现象：宠物精练内 锁定点击无反应 点击一下精力后 会变成锁定状态 点击解锁后无反应变化 也需要点击一次精炼后才会变成解锁状态
预期：点击锁定或者解锁会立马变化 不需要点击一次精炼
截图：

问题23：
状态：服务端已修复，验证通过（已看截图 image-2026-05-22T07-59-04-853Z / 07-59-08-229Z，客户端 ArenaBattleDialog/FightService.startAreaArena/ArenaOtherDefenseTeamDialog 以及战斗包 leftTeam/rightTeam.weaponId/petUId 读取链路，服务端 arena_startarea/fight_startareaarena/buildPlayerTeam/rolepetx 代码，Docker 与 2026-05-22 结构化服务端日志，以及 Mongo 当前角色数据。今天容器和结构化日志未查到 151830 的 fight_startareaarena 请求；Mongo 可定当前数据：对手 433288/549361 均有主线 lordWeaponId=9，但 arenaWeaponId=0、arenaPetUId=''，战斗入口原来直接用 targetRole.ArenaWeaponId/ArenaPetUId 构 rightTeam，所以客户端战斗里右侧玩具/宠物字段为空。根因：未设置防守阵容时 arena_startarea.syncDefenseTeam 只复制主线 BattleTeam 到 ArenaTeam，没有同步主线玩具/上阵宠物；历史已生成的 ArenaTeam 也会保留装备空值。已改为自动同步防守阵容时同时复制 LordWeaponId 和上阵宠物；fight_startareaarena 对防守方装备为空的历史数据回退主线装备，并补 defender equipment fallback 日志。验证：GOCACHE=/tmp/go-build go test . -run 'TestResolveArenaDefenseEquipment|TestArenaStartAreaSyncDefenseTeamCopiesMainEquipment|TestFightStartAreaArena_BuildPlayerTeamAppliesEquipmentBlessing|TestFightStartAreaArena_BuildPlayerTeamUsesRolePowerForSnapshot' 通过） 账号：fafa 密码：123456 ID:151830
现象：竞技场内 对方未设置防守阵容的情况下 挑战对方后 对方不会显示玩具
预期：未设置防守阵容时 根据当前主线阵容来定 正常显示玩具宠物等
截图：

问题24：
状态：服务端已修复，验收通过（已看截图 image-2026-05-22T10-05-23-648Z / 10-05-28-374Z / 10-05-32-429Z / 10-05-36-260Z、客户端 PetDataView/PetModule/PetEquipDialog/PetInfoQuenchDrawer 的 pet_load/slotUId/uId/quenches 读取链路、服务端 pet_load/HandleLoad/clientPetDataSnapshot/rolepetx 代码、2026-05-22 Docker 日志和 Mongo 角色 151830 数据。日志确认 17:58:58 上阵 502、18:01:10 上阵 204、18:18:53 上阵 502 时，pet_load 主回包里新上阵宠物 -1 的 quenches 均为空，原 601 的精炼只保留在被换回的格子；Mongo 当前也确认 502/503/302/204 的 q/pq 均为 0，只有 -1 的 601 有 6 条精炼。根因不是持久化真复制，而是 pet_load 成功后桥接层又额外推了一包全量 syncresp.roleInfo，里面包含完整 petData，会在主回包之后覆盖客户端 PetRoleDataView 的增量状态，导致宠物页/布阵页看起来其他宠物也带了 601 的精炼。已改为 pet_load 后额外同步只推客户端需要刷新的 roleInfo.heroes 和 power，不再推全量 roleInfo/petData；petData 只以 pet_load 主回包为准。补 TestHandleLoad_SwapsEquippedWithBoardPet 校验新上阵宠不继承旧宠精炼、旧宠精炼随自身回格子。验证：go test ./domains/pet -run 'TestHandleLoad|TestHandleQuench|TestHandleLockQuench'、go test . -run 'TestResolvePetMutationPowerUsesCalculatedHeroPower|TestBonusCalculatorCalculateTotalPowerAddsEquippedPetPower|TestBonusCalculatorAppliesEquippedPetQuenchToBattleHeroes' 通过）
现象：一个宠物精练后 其余宠物点击上阵会复制其精炼(宠物系统里或者武将布阵页面选择上阵都会)
预期：一个宠物精炼只能这个宠物使用 其余宠物上阵不会复制
截图：

问题25：
状态：验收通过（已补齐月华/惊雷服务端鱼灵 ItemConf/ArtifactConf 星级链，待客户端图鉴/升星/面板/战斗验收）
现象：鱼灵月华和惊雷不生效 属性加成不生效 加成不到面板 主动被动在战斗时也不生效
预期：属性加成正常生效 展示在面板 主动被动战斗时正常生效
截图：

问题26：
状态：验收通过（同问题25，已补齐图鉴识别和升星依赖的 ArtifactConf 星级链，待验收）
现象：月华 惊雷两条鱼灵 拥有后图鉴内无法点亮 无法升星
预期：拥有后可以正常点亮图鉴正常生星
截图：

问题27：
复现账号：fafa 时间2026.5.23 23:17
状态：已修复，待验证（2026-05-23 23:17 新日志实际触发 equipment_quench；已修复淬炼回包丢弃动态 heroResp、返回原始 hero.power 导致客户端覆盖成裸战力的问题；同时补齐 equipment_confirm 兼容回包）
现象：随机一个武将赐福或者取消赐福后 别的武将面板战力会变低
预期：赐福或者取消赐福不影响战力 战力锁死
截图：

问题28：
复现账号：fafa1 ID：401430 时间：2026.5.24 0:00
状态：服务端已修复，验收通过（已看截图 image-2026-05-23T08-20-06-610Z / 08-20-11-566Z、客户端 PetModule.checkPetNew/_sendMerge 与 PetHomeDialog._onPetBoardMerged、服务端 pet_merge/HandleMerge 回包裁剪逻辑、Docker 中 401430/fafa1 在 2026-05-24 00:15-00:18 的 pet_merge 日志。日志确认服务端每次 resultPetId/resultUId 明确，但协议只下发 keys；客户端弹新宠物不是读 resultPet/resultUId，而是从顶层 role.petData.pets 取第一个 uid。服务端原合成回包顶层 role.petData.pets 同时带删除槽 null 和结果槽，Map/JSON 顺序不稳定，导致弹窗/动画可能取到非结果宠或空槽。已改为顶层 role/roleInfo 的 petData.pets 只保留结果槽给客户端弹窗/动画使用，rawData.role/rawData.roleInfo 继续保留删除槽 null + 结果槽用于全局增量同步，并补 resultSlot。验证：GOCACHE=/tmp/go-build go test ./domains/pet -run 'TestHandleMerge|TestMergeTargetPet' 通过）
现象：每次合成出一个新宠物时跳出的动画显示的和实际获得的宠物不同
预期：合成的是什么宠物 显示的动画就是什么宠物的
截图：

问题29：
状态：服务端已修复，验收通过（已看截图 image-2026-05-23T08-28-05-753Z / 08-28-10-730Z、客户端 ArenaModule.getArenaRank/getAreaTarget 与 ArenaPanel 展示逻辑、客户端协议 Arena_GetAreaRankResp/Arena_GetAreaTargetResp、服务端 arena_getarearank/rankx.BuildResponse 与 arena_getareatarget/matchOpponents。Docker 当前 game-server 历史日志已轮换，server/logs 2026-05-23/24 也未保留 401430/fafa1 的 arena_getarearank/getareatarget 协议日志；Mongo 当前数据校验确认竞技场榜存在高于 1046 的全服分数。根因：服务端排行榜按当前玩家所在 100 人组返回本组榜，挑战目标却按全服 arenaScore±200 匹配，导致可刷出不在本组榜内的高分玩家，页面内看起来“榜内积分”和“实际挑战积分”不一致。已改为 arena_getareatarget 优先按当前玩家全服排名定位同一 100 人组，在组内按 ±200 分筛目标；组内分数带为空时回退组内候选，组内不可用才走旧全服兜底；并补 arena_getareatarget 日志输出 myGlobalRank/groupStartRank/mode/candidateCount/targets。验证：GOCACHE=/tmp/go-build go test . -run 'TestArenaGetAreaTarget|TestArenaStartArea|TestFightStartAreaArena|TestGenerateBattleRandomSeed' 通过）
现象：竞技场内排行榜显示的积分和实际的积分不一样
预期：排行榜内积分和实际积分一致
截图：

问题30：
状态：已修复，验收通过（已看截图 image-2026-05-23T08-30-46-752Z、客户端 ArenaBattleDialog/FightService.startAreaArena/manager-factory 对 battleData.leftTeam/rightTeam.weaponId 的读取链路、服务端 fight_startareaarena/buildPlayerTeam/getWeaponActiveLevel 和 Docker json 日志文件。现有日志未命中 fight_startareaarena 细节，但代码可定根因：竞技场专用 buildPlayerTeam 虽下发 weaponId，却把 weaponActiveLevelId 固定为 0；正常主线/精灵/进化塔战斗会按当前玩具计算主动技能等级。战斗服拿到 0 后无法挂载玩具主动技能配置，表现为双方玩具能量一直 0%、玩具无效。已改为按本次实际 weaponId 解析 weaponActiveLevelId，并补 fight_startareaarena battle_team 日志输出 side/roleId/weaponId/weaponActiveLevelId/petUId/teamSize；验证：go test . -run 'TestFightStartAreaArena|TestResolveArenaDefenseEquipment|TestArenaStartAreaSyncDefenseTeam|TestArenaTeamSnapshotPower|TestApplyArenaBattleScores|TestNormalizeArenaRecordList'，go test ./domains/core/competitive ./internal/geniex ./domains/activity/evotower 通过）
现象：竞技场内战斗时双方玩具怒气不增加 玩具无效
预期：玩具怒气增加 正常释放被动
截图：

问题31：
状态：已修复，验收通过（已看截图 image-2026-05-23T08-33-27-348Z、客户端 RoleDataView/LordModule/TipsManager/ArenaBattleDialog/ArenaModule、服务端 fight_startareaarena/buildArenaRoleSyncData 和 Docker json 日志文件。根因：客户端 LordModule._onSyncRoleBefore 只要收到 role.power 且比当前 ROLE.power 大就弹“战力提升”；竞技场挑战结算与战力无关，但服务端 fight_startareaarena 结算后把竞技场战斗快照 power 写进 roleData 并推 syncresp.role.power，导致客户端按全局主线战力变化弹窗。已改为竞技场结算只同步次数、积分、道具、金币/钻石等竞技场需要字段，不再下发 power；验证：go test . -run 'TestBuildArenaRoleSyncData|TestFightStartAreaArena|TestResolveArenaDefenseEquipment|TestArenaStartAreaSyncDefenseTeam|TestArenaTeamSnapshotPower|TestApplyArenaBattleScores|TestNormalizeArenaRecordList'，go test ./domains/core/competitive ./internal/geniex ./domains/activity/evotower 通过）
现象：竞技场每次挑战结束后都会弹出战力增长弹窗
预期：竞技场和战力无关 不会弹出战力增加的ui
截图：

问题32：
复现账号：
状态：已修复，待验证（已看截图 image-2026-05-23T08-35-43-962Z / 08-35-48-338Z、客户端 RoleDataView.heroEBuffMap/EquipEnchantData/EquipEnchantDialog 读取 ROLE.enchantMap 与装备 enchantUId 的链路、服务端 equipment_cancelenchant/equipment_enchant/SafeUpdateRole/RoleService.UpdateRole/RoleStore 代码和 Docker json 日志文件；现有日志未命中该截图对应的 equipment_cancelenchant 请求。服务端根因链路：取消最后一条赐福后必须把空 enchantMap 落库，并且后续非赐福旧角色快照保存时不能把旧映射覆盖回来，否则客户端刷新 ROLE.enchantMap 后会重新显示“赐福”。当前服务端已补齐两层保护：RoleService.UpdateRole 允许空 enchantMap 持久化；SafeUpdateRole 对非 equipment_enchant/equipment_cancelenchant 保存会读取最新 enchantMap 并覆盖旧快照，避免旧快照刷回；取消赐福回包对删除的 enchantMap key 下发 null。已补回归测试覆盖“非赐福旧快照不能恢复旧赐福”和“取消赐福允许持久化空 map”。验证：go test ./internal/rolepersist ./services ./internal/rolecachex ./internal/gameplay/enchantx，go test . -run 'Test.*Enchant|TestEquipment|TestBuildRoleUpdateFields|TestSafeUpdateRolePreservesLatestEmptyEnchantMapForNonEnchantSave|TestSafeUpdateRoleAllowsEnchantHandlerToPersistEmptyEnchantMap' 通过）
现象：赐福关闭后 过一会莫名奇妙又会恢复赐福状态
预期：赐福关闭后除非玩家手动去赐福不然不会自动恢复
截图：

问题33：
状态：未处理
（已看截图 image-2026-05-23T08-43-04-645Z / 08-43-07-866Z / 08-43-11-040Z / 08-43-16-791Z / 08-43-19-847Z、5-4 文档问题4、客户端 HeroExchangeDialog/HeroModule/RoleDataView/EquipEnchantData 的 hero_exchange 请求与 ROLE.heroes/ROLE.enchantMap/heroEBuffMap 增量刷新链路、服务端 hero_exchange/exchangeEquipmentExcludingPolished/normalizeExchangeEquipmentAndEnchantByHeroIDs/finalizeHeroExchangeResponse/SafeUpdateRole 保存链路，以及 2026-05-24 下午 Docker json 日志。第一段根因：无损换将已在 hero_exchange 中重映射/清理 enchantMap，但 SafeUpdateRole 之前把 hero_exchangeHandler 当成普通非赐福保存，保存前又从 DB 读取“最新 enchantMap”覆盖回内存中的清理结果，导致旧赐福映射重新落库。已修复 rolepersist 将 hero_exchange/repair_invalid_enchant 归为赐福权威保存，role_getroleinfo/buildRolePayload 登录与回包构建时会 NormalizeRole 清理历史非法 enchantMap 并落库。复测仍异常的根因与 5-4 问题4同类：服务端落库与当前角色态正确，但 hero_exchange 回包只强制下发交换双方和当前上阵武将，漏掉客户端仍缓存/展示的非上阵背包武将；客户端 RoleDataView 对 role.heroes 做增量合并，EquipEnchantData 又从 ROLE.heroes 重建淬炼/赐福来源，未下发的旧 hero 块会残留到本次界面，退出重进全量拉取后消失。下午 21:37 日志已定死服务端当前态正确：hero_exchange before_response/response_summary 中 120 已变为低淬炼，114 已获得高淬炼，enchantMap 为空。补充修复：finalizeHeroExchangeResponse 对 hero_exchange 下发完整原始 role.heroes，并且同步用 hero 块不再从 GetRoleWithBonusFromRole/动态加成视图构造，避免污染客户端原始 ROLE.heroes。22:44/22:48 新日志和客户端协议复查后定死第三段根因：客户端协议层只按顶层 role 更新 SERVER_DATA.role，RoleDataView 对 Map 是增量 merge；服务端回包中低淬炼装备只返回现有槽位，例如 quenches 只含 1 时，客户端不会自动删除旧的 2/3/4/5 槽，导致页面残留孔位/淬炼，重登全量重建 Map 才消失。已修复 buildEquipmentPayload 对 quenches/quenches2 补齐 1-5 缺失槽位的 null 删除标记。验证：GOCACHE=/tmp/go-build go test ./internal/rolepersist；GOCACHE=/tmp/go-build go test . -run 'TestPrepareRoleForRoleGetRoleInfo|TestSafeUpdateRole'；GOCACHE=/tmp/go-build go test ./internal/gameplay/herox -run 'TestNormalizeExchangeEquipmentAndEnchantByHeroIDs|TestHandleExchange_IntegrationPreservesBlessingAfterEquipmentSwap|TestFinalizeHeroExchangeResponse'；GOCACHE=/tmp/xianyu-go-build go test ./internal/gameplay/herox -run 'TestFinalizeHeroExchangeResponse|TestHandleExchange_IntegrationPreservesBlessingAfterEquipmentSwap|TestNormalizeExchangeEquipmentAndEnchantByHeroIDs'；GOCACHE=/tmp/xianyu-go-build go test ./internal/gameplay/herox -run 'TestBuildHeroPayload_EquipmentIncludesFullQuenchFields|TestBuildHeroPayload_QuenchPayloadIncludesDeleteMarkersForMissingSlots|TestFinalizeHeroExchangeResponse|TestHandleExchange_IntegrationPreservesBlessingAfterEquipmentSwap|TestNormalizeExchangeEquipmentAndEnchantByHeroIDs' 均通过）
复现账号：fafa id：151830 时间 2026.5.23 22:07
现象： 如下方截图 一个武将有淬炼 一个没有 无损换将后 变成两个都有淬炼和孔位 退出游戏在进入会消失
预期：无损换将是把两个武将淬炼孔位互换 不会存在从无到有
截图：

问题34：
复现账号：fafa1 id：401430 时间：2026.5.24 0:14
状态：待复现（已看截图 image-2026-05-23T08-50-37-190Z / 08-50-45-876Z、客户端 CollectionThemeSuitsDialog/CollectionModule/CollectionData 对 suitSeries.collectMap、claimedProgress/claimingProgress 和 collection_claimseries 的读取链路、服务端 collection_getinfo/collection_exchange/collection_claimseries/buildCollectionThemeSeries/collectionOwnsSeriesItem 代码、Docker json 日志和 Mongo 当前角色数据。当前没有服务端失败链路：401430/fafa1 在 2026-05-24 00:13:10/16/20 分别购买周瑜皮肤 10503、头像框 110503、PVP 背景 7006，日志均写入 collectionActivated；00:13:44 的 collection_claimseries 返回 code=0，不是“没有可领取奖励”拒绝。Mongo 当前确认 collectionActivated 只有 1:10503、6:110503、8:7006，collectionHeroSuitClaim.10503=3；吕布 10702/110702/7005 不存在，服务端数据不会点亮吕布皮肤。现已补 collection_claimseries 精准日志：no_reward/success 均输出 poolType、seriesId、progress、claimed、nextClaim、stages/rewards；下次若再出现可直接判断是服务端进度/已领判断还是客户端重复点击/缓存显示。验证：go test . -run 'TestBuildCollectionInfo|TestCollection|TestCollectionClaimedSuitBonuses|TestCollectionStageFlatBonus' 通过）
现象：周瑜三件套全部拥有时就点击领取缺显示无法领取 吕布没有皮肤却点亮了皮肤图案
预期：拥有什么就点亮什么 没有就不会点亮 达到对应件数就可以激活对应加成
截图：

问题35：
状态：服务端已修复，验收通过（已看截图 image-2026-05-23T08-56-25-060Z / 08-55-33-287Z、客户端 ActivityTimeModule/ActivityTimeContainerDialog/FishingActivity.PearlActivity、服务端 monthactivityx/auto_grant/pearlx/quench/activity_get、Docker 日志和 Mongo 邮件数据。根因：服务端 IsMonthActivityTaskEnabled 对灵贝消耗任务默认按配置存在即开启，且 month_activity_switches 中 taskType=4 为 true，和客户端当前月度活动页实际不展示灵贝活动不一致，导致消耗贝壳/灵贝仍触发 taskType=4 月度奖励邮件。已改为灵贝月度任务必须显式开关开启才计入/展示，当前配置关闭 taskType=4；activity_get 也按开关隐藏灵贝月度进度；举一反三补了周活动非当周活动 no-op，避免不在本周开放的活动写进度/发奖励。验证：GOCACHE=/tmp/go-build go test ./domains/activity/read ./internal/activityx ./internal/activity/monthactivityx ./entry/activity/activityentry 通过）
现象：月度活动中没有贝壳活动 但是消耗贝壳却发放消耗奖励
预期:消耗只计入当前已有活动
截图：

问题36：
状态：暂不修复（按要求问题36先不修；该问题为战斗动画表现/帧率类问题，后续若要处理需单独看客户端战斗播放代码、服务端 battleData、battle-worker 战斗步骤日志和录屏复现）
现象：所有战斗 战斗时1倍速战斗画面武将技能不流畅 2倍速武将大招技能不完全
预期：战斗画面流畅 武将技能画面完全
截图：

问题37：
状态：服务端已修复，待验证（已看截图 image-2026-05-23T09-02-58-298Z / 09-03-12-246Z / 09-03-01-716Z、客户端 PetInfoQuenchDrawer/PetModule/PetDataView/PetAttributeToolTip、服务端 pet_load/pet_quench/rolepetx/savePetData、2026-05-24 401430/fafa1 Docker 日志。根因链路与 38 同源：pet_quench 返回给客户端时把 PendingQuenches 叠成 petData.pets[*].quenches，客户端当前会话显示为已生效宠物属性；但服务端 rolepetx.PowerFromRole/Totals/BattlePetFromRole 只读正式 Quenches，刷新/重新上阵/切换宠物时才通过其它路径重算，表现为宠物战力加成掉落后切换恢复。已统一 rolepetx 使用 EffectiveQuenches：有 PendingQuenches 时按客户端当前展示值参与战力、战斗宠物下发和属性汇总；pet_quench 成功后额外推 hero_panel/power 增量刷新。验证：GOCACHE=/tmp/go-build go test ./internal/rolepetx ./domains/pet；GOCACHE=/tmp/go-build go test . -run 'TestNonExistent' 通过）
现象：宠物战力加成莫名奇妙会掉 需要重新佩戴或者切换一下宠物才会恢复
预期：当前上阵宠物和当前阵容战力锁死 不会出现莫名掉战力的情况
截图：

问题38：
状态：服务端已修复，验收通过
（复现账号 fafa1/401430，已看 2026-05-24 00:19 Docker 日志、截图、客户端 PetInfoQuenchDrawer/PetModule/PetDataView/PetAttributeToolTip、服务端 pet_quench/pet_quenchconfirm/rolepetx。日志确认 00:19:12/00:19:14 只有 pet_quench，没有 pet_quenchconfirm，且 role_power_audit delta=0；根因是服务端把 PendingQuenches 在回包中伪装成 quenches 让客户端显示“已生效”，但战力/武将面板/战斗下发仍只读正式 Quenches，导致精炼词条看见了却不加到武将/战斗。已改为 rolepetx.Totals/PowerFromRole/BattlePetFromRole 对当前展示的 pending 精炼也生效，pet_quench 后推 heroes/power 刷新。验证：GOCACHE=/tmp/go-build go test ./internal/rolepetx ./domains/pet；GOCACHE=/tmp/go-build go test . -run 'TestNonExistent' 通过）
复现账号fafa1 id：401430 时间：2026.5.24 0:19
现象：宠物精炼词条属性不生效 不加成到武将面板
预期：精炼词条属性正常生效 且显示在武将面板
截图：

问题39：
状态：服务端已修复，验收通过（已看截图 image-2026-05-23T09-15-34-496Z、客户端 BattleAttributeKey/Language NORMAL_DMG_ADD/NORMAL_DMG_RED、PetInfoQuenchDrawer 展示 attrId、服务端 petprob/pet_prob.json/rollQuenchAttrIDs。根因：客户端已存在普攻易伤/普攻抗性枚举与文案，精炼页直接展示服务端返回的 attrId；服务端 server/config/pet_prob.json 的 quenchAttrs 池缺少 attrId=504 NORMAL_DMG_ADD、505 NORMAL_DMG_RED，所以永远随机不出这两个新增词条。已把 504/505 加入宠物精炼随机池，并补测试校验随机池包含普攻易伤/普攻抗性。验证：GOCACHE=/tmp/go-build go test ./domains/pet 通过）
复现账号fafa1 id：401430 时间：2026.5.24 0:19
现象：宠物精炼词条不全 没有普攻抗性和普攻易伤等属性
预期：宠物精炼内的属性词条齐全
截图：

问题40：
状态：服务端已修复，验收通过（已看截图 image-2026-05-23T09-18-58-804Z、客户端 PetHomeDialog/PetModule 开蛋动画链路、服务端 pet_openegg/HandleOpenEgg、Docker 中 fafa1/401430 在 2026-05-24 00:17-00:18 的 pet_openegg 日志。根因：客户端动画不读取 resultSlot/resultUId，而是从响应 role.petData.pets 中取第一个 uid 再反查格子；如果服务端返回全量 pets 或响应里无法明确新宠物，动画就会落到第一个格子/空白。服务端已在开蛋成功后把 role/roleInfo/rawData.role/rawData.roleInfo 的 petData.pets 裁剪为仅新生成 slot，并返回 resultPet/resultUId/resultSlot，确保旧客户端按第一个 uid 也只能拿到新宠物。验证：GOCACHE=/tmp/go-build go test ./domains/pet 覆盖 open egg 响应只含新格子）
复现账号fafa1 id：401430 时间：2026.5.24 0:17
现象：点击宠物蛋开宠物时的动画不对 每次点击画面都会空白 显示宠物到第一个格子
预期：宠物出现在哪里动画就到哪里 动画正常流畅
截图：

问题41：
状态：服务端已修复，验收通过（已看截图 image-2026-05-23T09-24-52-087Z / 09-24-57-438Z / 09-25-00-702Z、客户端 DRV2Helper/DressingRoomV2/role_loaddress 外观装配链路、服务端 role_loaddress/rolecosmetics 默认外观白名单、Docker 中 fafa1/401430 2026-05-24 00:21 日志。日志确认客户端连续发起 role_loaddress，服务端返回 code=1 外观ID无效；根因是 collection_exchange 已发放新增周瑜头像框 110503 和竞技背景 7006，但 role_loaddress 使用的服务端外观白名单缺这两个 ID，导致佩戴被服务端拒绝。已补 BuildAllAvatarFramesForTest 包含 110503、BuildAllPvpMapsForTest 包含 7006，并补测试。验证：GOCACHE=/tmp/go-build go test ./internal/rolecosmetics；GOCACHE=/tmp/go-build go test . -run 'TestRoleLoadDress|TestBuildRoleLoadDress|TestHandleLoadDress' 通过）
复现账号fafa1 id：401430 时间：2026.5.24 0:21
现象：周瑜太上老君头像框和炉火丹青竞技背景点击装配无反应 无法正常装配
预期：点击佩戴可以正常佩戴
截图：

问题42:
状态：服务端已修复， 已通过（已看截图 image-2026-05-23T10-46-48-780Z / 10-46-52-823Z、客户端 TeamUpModule/NightmarePanel 的重连与进面板拉取 matchteam_getroleteaminfo 链路、服务端 nightmare_dismiss/matchteam_getroleteaminfo/matchteam runtime 代码、Docker 日志。当前容器日志起始时间晚于截图复现窗口，未找到 10:46 原始 trace；但代码路径可确定根因：nightmare_dismiss 非队长分支只删除 nightmareRT.roleRoom 并把房间置为关闭，没有清理 matchteamRT.roleTeam 和队伍 fightRoleBase，客户端大退后调用 matchteam_getroleteaminfo 会再次拿到旧 team，所以继续弹“队伍等待中”。已在非队长 dismiss 时同步走 matchteam dismiss，清理该角色组队绑定、队伍成员列表和十殿房间映射，并新增 nightmare_dismiss_matchteam_sync 窄日志便于下次复现直接定位。验证：GOCACHE=/tmp/go-build go test . -run 'TestNightmareDismiss_MemberClearsMatchTeamBinding' 通过）
现象：十殿打完房间解散后 还是会弹出十殿组队中弹窗 大退游戏在进入还是会弹出
预期：十殿队伍房间解散以后不会再有弹窗
截图：

问题43：
状态：服务端已修复， 验收通过（已看截图 image-2026-05-23T13-51-38-990Z / 13-51-36-117Z / 13-51-59-788Z、客户端 PetEquipDialog/PetModule/HeroTeamPanel 切宠物链路、服务端 pet_load 与 presetteam_saveteam/预设阵容应用逻辑、Docker 中 fafa/151830 在 2026-05-23 21:49-21:50 的日志。根因：21:49:29 pet_load 已上阵 uid=151830-1779435452124172306，但一键换阵后 21:50:03 再 pet_load 时服务端日志 prevUid=空，说明当前 -1 宠物被预设阵容应用清掉；代码 setEquippedPetUId 遇到目标宠物本来就在 -1 时跳过 -1 查找背包失败，直接 delete -1，导致宠物丢失。已改为：目标就是当前 -1 时保持；切到背包宠物时与当前上阵宠物交换；卸下时把当前宠物放回空格。验证：GOCACHE=/tmp/go-build go test ./domains/social/team ./domains/pet ./internal/rolepetx 通过）
账号：fafa id：151830 时间 2026.5.23 21:50
现象：使用一键换阵 换阵后在点击切换宠物 当前宠物就会丢失
预期：使用一键换阵后 切换宠物宠物不会丢失 而是回到背包
截图：

问题44：
状态：服务端已修复，验收通过（截图 image-2026-05-23T14-47-36-067Z / 14-47-41-583Z 显示“十殿试炼9”但右侧 boss 名为“秦广王”，不符合当前客户端配置。已看客户端 NightmarePanel/NightmareBattlePanel/NightmareModule 与 client/assets/config/config.json：当前包内十殿 9 是两个阶段，bossId=11 一阶段应为 5 个 1000901/3310091，bossId=12 二阶段应为 1 个 1000902/331009，maskName 均为“平等王”。已看服务端 nightmare_fight/buildNightmareRightTeamHeroes 与配置，根因：服务端 config1/config 内有 NightMareMonster 11/12，但缺 MonsterConf[1000901/1000902] 和 LevelCoeff[3310091/331009]；当容器读不到客户端配置时 buildNightmareRightTeamHeroes 返回空，nightmare_fight 又静默兜底成 10001/秦广王，导致十殿9战斗画面错 boss 且 HP 异常。已补齐服务端配置：server/config/config.json 与 config1.json 增加 MonsterConf[1000901/1000902]，server/config/levelcoef.json 与 levelcoef1.json 同步客户端 331009/3310091；并改为缺属性表时仍按 NightMareMonster.monsters 的怪物 ID 与 bossHp/bossAttack/bossSpeed 构造右方队伍，且彻底移除 nightmare_fight/auto_fight 的 10001 静默兜底，真构造失败只报“十殿怪物配置异常”并打 empty right team 错误日志。现有 Docker 日志未找到截图 battleId 1779547523142/1779547543432 对应 nightmare_fight trace；验证：GOCACHE=/tmp/go-build go test ./domains/pve/nightmare -run 'TestBuildRightTeamHeroes_(Nightmare9UsesClientStageMonsterAttrs|IgnoresLegacyBossOverrides|Nightmare9FallsBackToNightmareMonsterRow)'、GOCACHE=/tmp/go-build go test . -run TestNonExistent 通过）
现象：十殿9一二阶段boss不对
预期：十殿内十殿9一阶段二阶段boss是对应boss 切伤害血量正常
截图：

问题45：
状态：服务端已修复，待验证（复测新增 Docker 日志确认 2026-05-25 00:30-00:37 账号 11223311/角色 467000 与队友 425344 已通关十殿 1-8，服务端 nightmare_pass_progress_plan 计划写入 maxLevel=1..8、weekTime=1780243200、killAward/bookScore；但 00:40 后 nightmare_getroleinfo 仍回 maxLevel=0 levelRewardKeys=[1 2 3 4 5 6 7 8] killAward=map[] bookScore=0。已看截图、客户端 NightmarePanel 对 killAward、weekAward.levelReward、turntableLeftCnt/bookScore 的读取、服务端 persistNightmarePassProgress/claimNightmareWeekRewards/buildNightmareWeekAwardForRole/RoleStore dirty 写入链路和 Docker 日志，补充根因：十殿通关写入通过 RoleFieldStore.ApplyPatch 先写 RoleStore 内存并标记 dirty，但随后调用 invalidateNightmareRoleCache 删除 CachedRoleService/RoleStore，连 dirty 待 flush 记录一起删掉，导致 maxLevel/weekTime/killAward/bookScore 丢失，旧 levelClaim 残留并被 getroleinfo 原样回给客户端显示已领取。已修：十殿专用 invalidateNightmareRoleCache 不再删除 RoleStore，只清派生战力缓存；buildNightmareWeekAwardForRole 按 maxLevel 过滤不可能存在的旧 levelClaim，防止老脏数据继续误导客户端。十殿九未通过不影响该根因：日志只有 bossCfgId=11 失败，无 bossCfgId=12 通关。验证：GOCACHE=/tmp/xianyu-go-build go test . -run 'Test(BuildNightmareWeekAwardForRole_FiltersImpossibleStaleClaims|BuildNightmareKillAwardForRole_UnlocksUnclaimedMasks|AddRewardOpsToPatch_TreatsNightmareBellType46AsItem)'、GOCACHE=/tmp/xianyu-go-build go test ./internal/rolecachex 通过。）
现象：十殿通过对应关卡后队长无法解锁面具 入梦铃显示已领取 但是未到账无法抽奖
预期：通过对应关卡可解锁对应十殿面具 领取对应奖励 入梦铃需玩家手动领取 可以正常抽奖 每周刷新
截图：

问题46：
状态：服务端已修复，待验证（已看截图 image-2026-05-23T15-00-24-113Z / 15-00-28-180Z、客户端 SpecificsTeamDialog/SpecificsTeamDialogNew/HeroDataView 展示链路、服务端 Getrole/GetroleBonus/HeroHeroUpgradeLevelFieldized/rolepersist 代码、Docker 日志与 Mongo 角色数据。客户端该面板不本地计算攻击，直接显示服务端 role.heroes..attack；服务端根因是历史/部分字段化流程可能把“动态加成后的展示面板字段”残留到 heroes..attack/hp/defense/speed，后续 hero 升级与 Getrole 动态加成计算又把这些展示值当基础值继续乘星级/阶数/鱼灵/技能倍率，导致攻击数值膨胀。已在字段化武将升级前和 BonusCalculator/Getrole 计算前增加基础面板污染识别：按 HeroConf born 值、等级、职业成长推导基础面板，若当前基础字段超过合理范围则回落，并增加 hero_upgradelevel_normalize_base / hero_base_panel_normalize 窄日志便于复现定位。验证：GOCACHE=/tmp/go-build go test ./internal/gameplay/herox -run 'TestNormalizeHeroBasePanelFields|TestHeroHeroUpgradeStarFieldized_UsesAwakeRewardSkinInsteadOfSkinListOrder'、GOCACHE=/tmp/go-build go test . -run 'TestCalculateTotalSkillAttributes_MissingLordWeaponSlotDoesNotPanic|TestAddRewardOpsToPatch_TreatsNightmareBellType46AsItem' 通过）
现象：游戏内武将攻击数值过高
预期：攻击数值加成方式正确
截图：

问题47：
状态：服务端已修复，验收通过（已看截图 image-2026-05-23T15-02-55-269Z / 15-02-59-512Z、客户端 PearlDataView/PearlStageUpDialog/PearlSkillDescToolTip 与 BattleAttributeKey、服务端 Getrole/BonusCalculator/rankx 属性聚合、Docker battle worker 日志。客户端配置 pearlAttrConf.id=12 映射 BattleAttributeKey.RAGE_ADD=301，id=11 映射 HEAL_ADD=71；服务端鱼珠属性聚合只处理了 1-10、13-21，漏掉 12 的怒气速率和同类 11 的治疗增强，导致 battle worker 入参 fighters.attributes 中没有 301，使用前后怒气恢复无变化。已在服务端登录/Getrole、BonusCalculator、排行查看链路补齐 11->71、12->301 的鱼珠属性映射，并按客户端 maxValue 比例计算。验证：GOCACHE=/tmp/go-build go test . -run 'TestPearlAttrBonusValue|TestYuzhu_MissingPearlDataDoesNotPanic|TestSafeLordWeaponPassiveSkill_MissingWeaponDoesNotPanic'、GOCACHE=/tmp/go-build go test ./internal/gameplay/rankx 通过）
现象：游戏内灵珠冥想和鱼灵淬炼词条怒气速率不生效 使用前后怒气恢复没区别
预期：灵珠冥想和鱼灵淬炼词条怒气在战斗时正常生效
截图：

问题48：
状态：服务端已修复，验收通过（前次只修了 fight_startareaarena；2026-05-24 下午复测日志确认玩家实际触发的是 fight_startpvp，battle-worker 多次返回 mode=32 randomSeed=6。客户端 RankModule.sendPlayerDuelPVPBattle 只发送 targetId/battleVersion 并直接播放服务端 battleData；服务端 internal/modulehandlers/pvp.BuildStartPVPBattleData 仍写死 randomSeed=6，同模块 BuildStartConquerBattleData 也同样写死。已改为 PVP/争霸每场生成正随机 seed。验证：GOCACHE=/tmp/go-build go test ./internal/modulehandlers/pvp）
现象：游戏内武将战斗时 武将攻击随机值有问题 打同一个人不管多少次 永远都是同样的攻击那几个
预期：武将是随机攻击时 应完全随机 不会每次都一样
截图：

问题49
状态:服务端已修复，验收通过

（已看截图 image-2026-05-23T19-50-57-310Z / 19-51-19-566Z / 19-51-33-515Z / 19-51-49-579Z、客户端 PetConstData/PetInfoUpgradeDrawer/战斗 system-battle-start/system-level-start、服务端 rolepetx/zhurenlv/SkillSchemeConf、Docker 中 151830 宠物上阵/升级/精炼日志。根因：客户端展示和战斗创建都会使用服务端返回的 passiveSkillConfIds/petPassiveSkillIds；服务端已解锁被动 ID，但武将面板/战力计算只把宠物基础属性和精炼属性加到英雄，没把宠物被动 SkillSchemeConf.attrs 合入；同时服务端 SkillSchemeConf.json 缺少客户端已有的宠物被动方案，例如 5030103 技能伤害+9.6%、6030205 普攻抗性/治疗增强。已同步宠物被动 SkillSchemeConf 条目到服务端，并在 equippedPetHeroBonus 中把已解锁宠物被动 attrs 合入英雄属性，同时精炼使用 EffectiveQuenches。验证：GOCACHE=/tmp/go-build go test . -run 'TestBonusCalculatorAppliesEquippedPet(PassiveSkillAttrs|Quench)|TestBonusCalculatorCalculateTotalPowerAddsEquippedPetPower' 通过；GOCACHE=/tmp/go-build go test ./domains/pet ./domains/social/team ./internal/rolepetx 通过。全量 go test . 仍有既有无关失败项，未作为本问题阻塞）
现象:所有宠物被动不生效 被动加成不显示在面板
预期:所有宠物被动正常生效 加成正常显示在面板
截图:

问题50:
状态:服务端已修复，验收通过（已看截图 image-2026-05-24T00-01-19-494Z / 00-01-41-385Z、客户端 WeaponInfoDialog/WeaponInfoDialogV2/WeaponRebornSelectDialog/WeaponRebornConfirmDialog/WeaponModule 的 lordweapon_exchange 调用链、协议 GDLordWeapon.passiveSkill、服务端 lordweapon_exchange/LordweaponExchangeFieldized 代码和 Docker 玩具日志。当前 Docker 未查到清晰 lordweapon_exchange 复现请求，但代码根因可定：服务端转换只对两边已存在的 passiveSkill 节点按槽位交换等级；历史/目标玩具缺被动节点时 limit=min(lenA,lenB) 导致缺失槽位不交换，所以表现为只转换玩具等级，被动培养未完整跟随。已改为转换前按玩具 ID 与当前阵容星级补齐已解锁被动槽位，再按槽位交换等级并回包完整 passiveSkill；补 lordweapon_exchange 诊断日志输出 passiveCount/swappedPassiveSlots。验证：GOCACHE=/tmp/go-build go test ./internal/gameplay/lordweaponx 通过）
现象:玩具无损转换另一个玩具时 只转换了玩具等级 被动技能不跟着转换
预期:失踪无损转换时被动技能一起跟着转换
截图:

问题51：
状态：服务端已修复，验收通过（已看截图与 2026-05-24 下午 151830/fafa 日志；pet_quenchconfirm 多次返回 code=3 “精炼确认数据已过期”，客户端 PetInfoQuenchDrawer 在点击精炼前会先调用 pet_quenchconfirm，失败后静默停止，所以表现为点击没反应。根因是服务端把精炼结果写入 PendingQuenches，仅在 pet_quench 响应快照里临时覆盖成 quenches 给客户端显示；客户端 GDPet 协议和页面只读 quenches，重登读角色数据时不走该临时覆盖，显示又回到旧 Quenches。已根治为服务端精炼成功立即写入权威 Quenches 并清空 PendingQuenches，战力/战斗宠物/响应快照都只读 Quenches；确认接口只校验当前 Quenches，不再使用旧 Pending 流程。验证：GOCACHE=/tmp/go-build go test ./domains/pet ./internal/rolepetx）
现象：宠物精炼后词条不管锁不锁定退出游戏在进入 都会恢复最开始的词条 且点击精炼无反应 需开启自动精炼才会进行精炼
预期：当前词条是什么就是什么 退出游====戏再进不会变化 且点精炼就可立马精炼
截图：
退出再进：

问题52：
状态：服务端已修复，验收通过（已看截图 image-2026-05-24T07-18-25-513Z、客户端 PearlDataView/PearlSkillGetDialog/SkillSchemeConf/战斗 skill-create-helper 与 effect-attribute/effect-treatment 链路、服务端 fight_handler/competitive.BuildLeftTeam/pkroom_runtime 代码、2026-05-24 下午 151830/fafa Docker 日志和 Mongo 当前灵珠/阵容数据。客户端战斗只从 battleData.team[*].skill 创建 SkillScheme，仁心 1033015 依赖 HEAL_ANY 触发护盾，定心 1033009 依赖 START 触发 RAGE_R 属性；服务端主线/塔 buildLeftTeam 会追加灵珠 skillId，但 PK 房 buildPKFightBattleTeam 手写战斗队伍时把 skill 固定为空数组，绕过武将主动/被动、鱼灵被动和灵珠技能，导致切磋/PK 类战斗里“所有灵珠不生效”。已改为 PK 战斗队伍复用 extractActiveSkillIDs，并保留 activeSkill 规范化和 artifactId。验证：GOCACHE=/tmp/go-build go test . -run '^TestPKFightRole_BattleTeamUsesClientShape$' 通过；同组更宽测试中 TestPKRoomRuntime_UpdateRoleBattleInfo_SyncsWatcherAndFighter 仍有既有 watcher power 断言失败，非本次灵珠技能链路）
现象：灵珠仁心和定心不生效 可以查一下所有灵珠
预期：所有灵珠上阵正常生效
截图：

问题53：
状态：服务端已修复，待验证（复测不通过后复查。已看截图 image-2026-05-24T08-59-11-366Z，客户端 TowerModule/TowerMainPanel 普通层奖励读取 TowerConf.bossReward，服务端 towerx.FightStartTowerFieldized/compat 发奖代码，2026-05-24 下午 151830/fafa Docker 日志。日志显示通关第 10 层时服务端 fight_starttower[reward_plan] 读取并发放的是 TowerReward 宝箱档位奖励 1001x10，而截图/客户端普通层展示的是 TowerConf.bossReward 的金币 10000 + 进阶石 1003x10，因此不是到账写库失败，而是服务端通关奖励取错配置表。已根治为通关发奖按当前层 TowerConf.bossReward 发放并回传 role.gold/role.items，TowerReward 仅保留给宝箱领取入口；第 10 层体力奖励也从 bossReward 配置读取，不再硬编码额外叠加。验证：GOCACHE=/tmp/xianyu-go-build go test ./internal/gameplay/towerx；GOCACHE=/tmp/xianyu-go-build go test . -run 'TestGetTowerRewardItems_DoesNotInjectDryFishBonus|TestFightStartTower|TestTower'）
现象：咸将塔内每爬一层塔的奖励 进阶石和金币不到账
预期：所有奖励实时到账
截图：

问题54：
状态：服务端已修复，验收通过（已看截图 image-2026-05-24T09-13-54-501Z/image-2026-05-24T09-13-58-096Z、客户端 ArenaPanel/BattleUIManager/CommonBattleDetailsDialog 战斗详情读取 result.sponsor/accept.teamInfo 的 damage/takeDamage/treatment、服务端 fight_startareaarena/buildArenaRecordPayload/战斗服响应结构、2026-05-24 下午 151830/fafa Docker 日志。根因：战斗服响应本身支持 sponsor/accept.teamInfo，但竞技场服务端成功调用战斗服后只手动组装 isWin/round/totalFrame/statistic，丢弃 sponsor/accept；后续 ensureArenaBattleResultTeams 只能按 battleData 兜底生成 teamInfo，伤害/治疗/承伤全为 0，客户端详情因此显示空白/全 0。已改为 PVP 战斗服结果构造保留 sponsor/accept.teamInfo，竞技场战报 payload 直接保存真实明细。验证：GOCACHE=/tmp/go-build go test ./internal/modulehandlers/pvp；GOCACHE=/tmp/go-build go test . -run 'TestFightStartAreaArena_(BuildArenaRecordPayloadPreservesBattleStats|RecordPayloadUsesBattleDataResultShape|RecordPayloadUsesTypedTeamInfoShape|EnsureBattleResultTeamsMarksLoserDead)'）
现象：竞技场记录里战斗伤害数据详情显示空白
预期：有完整的战斗战斗伤害数据
截图：

问题55：
状态：服务端已修复，验收通过（复测不通过后复查。已看截图 image-2026-05-24T09-17-27-057Z/image-2026-05-24T09-17-21-136Z、客户端战斗结算详情按钮/CommonBattleDetailsDialog 读取 result.sponsor/accept.teamInfo、服务端 fight_startpvp/pkroom_startbattle 与 PVP 结果构造代码、2026-05-24 下午 151830/fafa Docker 日志。根因补充：复测日志 19:08:13/19:08:30/19:08:43 显示实际切磋入口是 fight_startpvp，不是之前修的 pkroom_startbattle；该入口成功调用战斗服后仍使用 BuildBattleServiceResult 重建结果，只保留 isWin/round/totalFrame/statistic，丢弃战斗服 sponsor/accept.teamInfo，随后 EnsurePVPResultTeams 只能按 battleData 兜底生成 damage/takeDamage/treatment 全 0 的明细。已改为 fight_startpvp 也使用 BuildBattleServiceResultWithTeams 保留战斗服 sponsor/accept.teamInfo，并补日志打印 sponsorTeam/acceptTeam 数量；pkroom_startbattle 已保持同口径。验证：GOCACHE=/tmp/go-build go test ./internal/modulehandlers/pvp；GOCACHE=/tmp/go-build go test . -run 'TestGetTowerRewardItems_DoesNotInjectDryFishBonus|TestFightStartPVP|TestPVP|TestBuildBattleServiceResult'）
现象：切磋后战斗数据详情显示为空
预期：正常显示战斗数据
截图：

问题56:
状态：服务端已修复，验收通过（已看截图 image-2026-05-24T10-58-00-548Z、客户端 PetInfoQuenchDrawer/PetModule/SpecificsTeamTotalDialog/RoleDataView、服务端 pet_quench/pet_quenchconfirm/pet_useexpitem/pet_load/pet_switch 与宠物加成计算、2026-05-24 151830/fafa Docker 日志。根因：客户端武将属性面板读全局 ROLE.heroes.*.calculateAttack/Hp/...，同步系统只按顶层 role 更新 SERVER_DATA.role；服务端宠物精炼/佩戴后额外推送的 syncresp 只有 roleInfo.heroes/power，客户端不会把它合并到 ROLE，而常规宠物响应里的 role 只含 petData/pet/items/power，没有最新 heroes，所以面板要重登后通过完整 role_getroleinfo 才刷新。另 pet_useexpitem 可能解锁/升级被动但原来没有推武将面板增量。已改为宠物影响面板后统一推 syncresp 的 role + roleInfo 双字段，并纳入 pet_useexpitem；日志会打印 keys=role,roleInfo。验证：GOCACHE=/tmp/go-build go test . -run 'TestBuildPetHeroPanelRoleDelta|TestPushTrumpRoleSyncResp'；GOCACHE=/tmp/go-build go test ./domains/pet）
现象：宠物精炼词条加成不会立马生效 需要图退出游戏再进才会生效显示在武将面板
预期：：宠物精炼词条洗出来后或者更换宠物后 词条会立马生效 展现在武将面板
截图：

问题57：
状态：服务端已修复，验收通过（已看截图 image-2026-05-24T11-04-10-678Z/image-2026-05-24T11-04-15-404Z、客户端 PetEquipDialog/PetModule/SpecificsTeamTotalDialog/RoleDataView、服务端 pet_load/pet_switch/pet_useexpitem 与宠物被动加成计算、2026-05-24 151830/fafa Docker 日志。根因同问题56：宠物佩戴/切换后服务端已重算 power，日志有 pet_load sync hero_panel，但额外推送只有 roleInfo，客户端同步根对象不消费；pet_switch 原来还没有触发武将面板增量推送，红宠转换/被动变化后只能等重登完整拉取。已改为 pet_load/pet_quench/pet_quenchconfirm/pet_switch/pet_useexpitem 成功后都推客户端可消费的 role.heroes/power 和兼容 roleInfo.heroes/power。验证同问题56）
现象：切换宠物后或者佩戴宠物后被动不会立马生效 不会立马加成在面板 需要退出游戏在进入才会显现
预期：佩戴宠物或者更换宠物 被动会立马生效 展现在武将面板
截图：

问题58：
状态：已修复 验收通过
现象：排行榜-主页-战斗时战斗力显示不一致
预期：三个地方战力永远一致 实时刷新
截图：

问题59：
状态：待排查
状态备注：待排查。已看截图，现象是十殿星级挑战战斗画面显示挑战失败；当前缺少对应协议日志/角色数据，还不能定死是战斗结果 isWin、回合数星级判定，还是客户端结算页读取路径错误。下一步需要沿十殿/梦魇星级挑战的 start/settle 协议检查服务端 battleResult.isWin、round 和客户端胜负展示条件。
现象：十殿内 星级挑战 打过了显示失败
预期：赢了就是赢了 根据回合数判定星级
截图：

问题60：
状态：已修复部分
备注：攻击血量加成不生效 复测时间 5.29 17：29 账号 fafa1
状态备注：已定位并修复部分根因，待回归验证。服务端宠物精炼红色词条仍走全局单双词条概率，导致红色也可能单属性；已改为红色词条固定双属性，见 server/domains/pet/service.go，测试 TestRollQuench_RedAlwaysHasTwoAttrs 已通过。截图中“词条加成不生效”还需要用角色数据/日志验证面板和战斗加成链路，暂不直接改状态为已修复。
现象：宠物精炼词条不对 红色词条是会是单属性 且词条不足 词条加成也不生效
预期：如截图2 红色词条全部是双属性 所有词条都会有 如截图3 所有词条加成正常生效
截图：
截图2：
截图3：

问题61：
状态：验收通过
状态备注：暂不能定死为代码 bug。截图中姜维 Lv6000 速度 3612，与当前服务端 HeroConf[114].speedBorn=12、职业成长 speedMul=0.6 以及客户端预览公式计算结果一致；缺少“正确基础速度”的策划配置或对服基准值，不能靠猜改配置。
现象：武将姜维基础速度不对
预期：基础速度正确
基础速度 无任何加成：
司马懿：1级 13 6000级3123
曹仁：1级11 6000级2722
甄姬：1级13 6000级2819
郭嘉：1级13 6000级3201
典韦：1级11 6000级2437

姜维：1级13 6000级2772
关羽：1级13 6000级 3222
黄月英：1级11 6000级2777
诸葛亮：1级13 6000级2802

周瑜：1级13 6000级2782
孙策：1级11 6000级2601
太史慈：1级13 6000级2714
孙坚：1级11 6000级2674
鲁肃：1级12 6000级2765

吕布：1级13 6000级3638
公孙瓒：1级14 6000级3007
华佗：1级11 6000级2964
贾诩：1级14 6000级3133
张角：1级12 6000级2782
截图：

问题62：
状态：已修复 验收通过
状态备注：已定位并修复，待回归验证。客户端成员管理弹窗允许团长直接把任意成员选为“团长”，发 legion_changejob {roleId, job:1}；服务端 ChangeJob 却只允许副团长升团长，普通成员会返回 code=9，客户端该路径不展示错误，表现为确认后无反应。已改为团长可直接转让给任意成员，原团长降为普通成员，见 server/domains/legion/member/member.go，并补回归测试。
现象：俱乐部内团长无法转让 点击确认转让无反应
预期：团长可以转让给他人
截图：

问题63：
状态：已修复 验收通过
状态备注：已定位并修复，待回归验证。服务端宠物使用本源蛋壳转换时只替换 PetId 后调用 1 级基础属性初始化，未按当前宠物等级重算攻击/血量，导致满级宠物显示 1 级加成；已改为转换后按当前等级刷新基础属性，并补了宠物合成继承等级后的同类修复，见 server/domains/pet/service.go，相关测试已通过。
现象：宠物使用本源蛋壳转换为另一个宠物后 转换后宠物攻击血量变成了1级的加成
预期：宠物转换成新宠物后 跟具宠物等级正常显示改等级加成的血量攻击 截图一是转换后的满级宠物 截图二是正常的满级宠物
截图1：
截图2：

问题64：
状态：已修复 验收通过
状态备注：已定位并修复，待回归验证。客户端咸主信息里“反叛”按钮发送 FightService.startRevolt，对应协议为 fight_startrevolt；服务端只实现并注册了 fight_startconquer，没有 fight_startrevolt。咸主面板反叛分支又没有判断错误码，拿默认空 battleData 进入战斗，导致截图中左右阵位为空、战力 0 并卡在战斗页。已补服务端 fight_startrevolt 注册和 handler，复用征服战斗构造但设置 isConquer=false，并让征服/反叛战斗使用客户端传入的 battleVersion，见 server/pvp_module_handlers.go、server/entry/account/wsentry/registry.go、server/internal/modulehandlers/pvp/battle.go，回归测试已通过。
现象：被别人击败成为咸臣时 客厅内点击反叛 对战页面卡死 必须退出游戏再进才正常
预期：点击反叛正常进入战斗界面
截图：

问题65：
状态：已修复 待验证
状态备注：已定位并修复，待回归验证。客户端 config_ap1.genieLevelConf 中灯神 16/17 关 bossReward 含 type=20 特权 7/8/9/10，对应彩玉/白玉淬炼特权；服务端 DB 版 genie_rewards.json 只保留 1022/1023 普通道具，且通用奖励落库只处理金币/钻石/道具，跳过 type=20，所以通关后特权不会写入 role.privilege。已改为灯神胜利奖励从关卡配置补齐缺失特权，并让 type=20 写入 role.privilege 回包触发客户端刷新，见 server/internal/geniex/startfight.go、server/internal/rewardstoreapply/apply.go、server/models/role.go，相关测试已通过。
现象:灯神挑战内 灯神16.17关通过后 彩玉白玉特权不生效
预期：获得的彩玉白玉特权正常生效
截图：

问题66：
状态：已修复 验收通过
状态备注：已定位并修复，待回归验证。客户端普通科技重置发送 legion_resetresearch {advanced:false}；服务端 Reset 用该标记过滤科技类型，只重置 researchType=0 的普通科技，明确跳过 researchType=1 的高级科技，导致普通重置后高级科技残留。已改为普通重置覆盖普通+高级，高级重置仍只重置高级，见 server/domains/legion/tech/research.go，并补回归测试。
现象：重置普通科技时高级科技不会一起重置
预期：重置普通科技 高级科技会跟随一起重置
截图：

问题67：
状态：已修复 验收通过
状态备注：已定位并修复，待回归验证。客户端周活动红淬达标页按“当前前 5 武将红色淬炼槽总数”展示进度，且领取请求不带具体档位；服务端 claimRedQuenchReward 原来按“本周新增红淬数”计算，打开活动时把当前红淬数记为 startNum 再相减，导致已有红淬的玩家客户端显示 20/20、40/40 可领，服务端却判定未达标并返回错误码，客户端未展示错误所以表现为点击无反应。已改为服务端与客户端一致，按当前前 5 武将红淬总数判定并自动领取第一个未领档位，见 server/internal/activity/claimbridge/handlers.go，回归测试已通过。
现象：限时活动周活动内红淬达标 达标后点击领取无反应
预期：达标后可正常领取奖励
截图：

问题68：
状态：已修复 待验证
状态备注：根因已定并修复。已看截图中“定心”说明为受减怒效果时 80% 概率免疫；客户端战斗 effect-attribute-funcs.js 减怒逻辑读取战斗属性 303(RAGE_R) 做免疫概率，SkillSchemeConf 中定心 1033009 正确配置 attrs[{type:303,value:0.8}]；服务端 fight_handler.getPearlSkillID 只把灵珠 skillId 追加到 battleData.team[].skill，competitive.BuildLeftTeam 原样发送 hero.Attribute，未把灵珠技能方案属性合入 battleData.team[].attribute，导致客户端读不到 303。已在 domains/core/competitive.BuildLeftTeam/BuildLeftTeam2/BuildLeftTeam3 按战斗技能列表合入 SkillSchemeConf.attrs，主入口 fight_handler 接入 getActiveSkillAttrMap。验证：GOCACHE=/tmp/go-build go test ./domains/core/competitive、GOCACHE=/tmp/go-build go test . -run 'TestBuildLeftTeam_(IntegrationAppliesPearlDingxinAttr|IntegrationIncludesCooperationFishPassiveSkill)' 通过。日志暂缺，本问题按配置/协议链路和回归测试定根因。
现象：灵珠定心不生效
预期：正常生效 有百分之80几率免疫减怒
截图：

问题69：
状态：已修复 验收通过
状态备注：已定位并修复，待回归验证。服务端防御公式把头冠开孔/装备防御放在倍率链之后当最终平值加，导致 0 加成和满加成在高面板下几乎无差异；已改为与攻击、生命一致先进入基础防御再吃星级/阶数/军团等倍率，见 server/role_handler.go、server/zhurenlv.go，回归测试已通过。
现象：装备内头冠开孔加成的基础防御不到面板 0加成和满加成防御面板显示是一样
预期：防御加成乘区正确 正常加成到面板 截图二是别的服0开孔和开孔加成满的区别
截图：


截图2：

问题70:
状态：已修复 验收通过
状态备注：已重新定位并补齐修复，待回归验证。2026-05-29 16:29-16:30 测试服日志显示 store_setpurchase 收到并回包成功 但 storePurchaseCnt/storePurchase/storePurchaseHistory 不在 models.Role 中，RoleStore 对这些字段走 fallback 后反序列化回角色模型时丢弃未知字段，导致随后 store_purchase 读取仍是 purchaseCnt=0 items=[]，出现“没有采购到任何商品”。已把采购清单/历史纳入角色模型并补 RoleStore fast set/get，新增回归测试覆盖“保存后立刻读取采购清单”；此前折扣浮点归一化修复保留，见 server/models/role.go、server/internal/rolecachex/store.go、server/internal/rolecachex/store_test.go、server/internal/gameplay/storebatch/purchase.go、server/compat_ws_bridge.go。
现象：黑室内一键采购不能正常采购
预期：设置好采购物品和次数后可以一键采购
截图：

问题71：
状态：验收不通过 账号fafa1 触发时间 5月30 15:50
状态备注：暂不能定死当前代码仍有该 bug。已检查服务端皮肤加成选择器，当前逻辑按“已拥有皮肤中最高 attrOrder/加成”计算，不依赖当前穿戴皮肤，并已有单测覆盖；截图可能是旧版本逻辑或特定角色皮肤拥有数据缺失。需要角色数据/日志确认 hero.Skin 是否包含朱雀皮肤、切换协议回包是否带动态属性后再决定是否修。
现象：切换皮肤后 当前武将战力会下降
预期：更具现有皮肤最高加成的去加成 不会出现更换皮肤战力变化的情况 皮肤加成战力锁死
截图：

问题72：
状态：已修复 验收通过
状态备注：已定位并修复，待回归验证。无损换将保存时保持基础属性是对的，但交换后 finalizeHeroExchangeResponse 强制把所有英雄用基础 buildHeroPayload 注入回包，覆盖了动态加成后的属性/战力，客户端合并后面板从几十亿掉到几十万。已改为注入回包时优先使用动态合并后的英雄数据，见 server/internal/gameplay/herox/exchange_handler.go，同时保留“不把动态属性写回库”的测试约束。
现象：无损换将后 会使当前上阵的所有武将面板战力和属性数值会变的极低从几十亿到几十万
预期：无损换将后不会出现所有武将面板战力和属性数值变低的情况
截图：

问题73：
状态：已修复 验收通过
状态备注：已定位并修复，待回归验证。服务端怪异寻宝移动后持久化已删除旧格子，但回包只返回新格子，未给客户端 Map 合并协议发送旧格子的显式 null 删除标记；客户端缺 key 不会删除旧 UI，所以看起来分化出同样怪物，重登后因 DB 正确又消失。已补删除标记，见 server/domains/activity/mergebox/compat.go，相关测试已通过。
现象：怪异塔怪异寻宝内 怪物拉倒相邻的格子后会分化出同样的怪物 退出游戏再进会消失
预期：不会分化出同样的怪物
截图：

问题74：
状态：已修复 验收通过
状态备注：已定位并修复，待回归验证。两个怪物合成后服务端状态已清理来源格，但回包没有对来源格下发显式 null 删除标记，客户端 Map 合并保留旧怪物。已在合成/自动合成/移动等回包中补齐删除标记，持久化状态保持干净，见 server/domains/activity/mergebox/compat.go，相关测试已通过。
现象：怪异寻宝内两个一样的怪物合成一个高级怪物后 原本的怪物不会消失
预期：两个同样的怪物合成高级怪物后 原本的连个怪物会消失
截图：

问题75：
状态：已修复 验收通过
状态备注：客户端根因已定并修复，待真机/预览验证。已看 4 张截图，入口分别为鱼珠加成、淬炼、灯神挑战、咸将塔等问号规则按钮，均走客户端本地 HelpTextDialog/CommonComplexTip/CommonComplexMultiTip 帮助弹窗，不触发服务端协议。根因是通用规则弹窗每次打开会同步执行文本排版/纹理测量，短规则文案也进入 StringUtil.getWrapperStr 的重排路径；同时低内存策略把 UI_HelpTextDialog 纳入自动释放，关闭后再次点击要重新构建 UI，表现为所有问号点击先卡顿一会。已改为短文本直接赋值显示、超长文本才走拆分测量，并从低内存自动释放列表移除 HelpTextDialog。涉及客户端文件：HelpTextDialog.js、CommonComplexTip.js、CommonComplexMultiTip.js、LowMemoryDeviceTask.js。验证：node --check 四个改动文件均通过；该项无服务端根因和服务端日志链路，需客户端预览/真机点击问号验证卡顿是否消失。
现象:游戏内所有问号图标规则介绍的点击后都会卡一会才会正常
预期：点击后不会卡顿
截图：

问题76：
状态：已修复 验收通过
状态备注：根因已定并修复。已看截图，客户端 HangUpDialog 的“升级1次”调用 HangUpModule.sendHangUpUpgrade(system_hangupupgrade)，成功后因服务端升级把 activeOrder 清 0，客户端会自动补发 system_activehanguporder；服务端 corehangup.ActivateOrder 原逻辑在激活订单时把 hangUp.lastTime/checkTime 改成当前时间，而客户端“已挂机时间”由 HangUpModule.passTime = serverTime - ROLE.hangUp.lastTime 计算，所以每次升级后看起来挂机时间刷新/归零。已改为激活挂机订单只更新 activeOrder，不再刷新 lastTime/baseTime/checkTime；升级本身也用测试约束不改计时字段。验证：GOCACHE=/tmp/go-build go test ./domains/core/hangup、GOCACHE=/tmp/go-build go test . -run 'TestBuildActiveHangUpOrderResponse_UpdatesBeforeReadingOptimizedRole'、node --check client/assets/game/scripts/HangUpDialog.js && node --check client/assets/game/scripts/HangUpModule.js 通过。日志暂缺，本问题按客户端协议链路、服务端状态写入路径和回归测试定根因。
现象:游戏挂机奖励内 每次升级 挂机时间都会刷新
预期：升级不影响挂机时间
截图：