==# 最新bug反馈 2026.5.14==================
问题1：
状态：已修复 验收通过
现象：激活典韦四圣后 四圣皮肤没到账 但是确有巨灵神皮肤 只有主线关卡显示皮肤
预期：四圣皮肤正常到账 巨灵神皮肤未获取不会拥有
截图：

问题2：
状态：已修复 验收通过
现象：鱼灵升星后图鉴不会立马更新需要退出重新进才会更新 且不需要手动升星点亮图鉴
预期：鱼灵升星后图鉴同步更新 且图鉴需要手动升星点亮
截图：

问题3：
状态：已修复 验收完成
现象：四圣升阶突破时使用连点器一直点击会跳随机阶
预期：四圣升级只能一阶一阶增加 不会出现跳阶
截图：

问题4：
状态：已修复 验收完成
现象：武将星级满级时 100级时被动2觉醒后 被动3被动4也可以直接觉醒 不需要达到等级要求
预期：被动2需要200级 被动3需要300级 被动4需要700级才可以解锁觉醒
截图：

问题5：
状态：已修复 验收完成
现象：锁定的淬炼词条解条解锁后 切换页面再看还是锁定状态 且推不掉这条洗练
预期：解锁了就是解锁了 点击淬炼可以推掉这条淬炼
截图：

问题6：
状态：已修复 验收完成
现象：淬炼时会出现同属性词条
预期：一个属性词条只会有一个 不论颜色等级
截图：

问题7：
状态：已修复 验收通过
现象：赵云激活四圣后佩戴四圣皮肤游戏就会卡死
预期：佩戴赵云四圣皮肤不会出现卡死情况 可以正常进行游戏
截图：

问题8：
状态：已修复 验收完成
现象：黑市内使用耀皮肤币兑换皮肤 无法正常兑换
预期：可以正常兑换并到账
截图：

问题9：
状态：已修复 验收完成
现象：吕布 周瑜 姜维 关羽 四个武将激活后点击升级升星等会显示英雄不存在
预期：激活后可以正常进行升级等操作
截图：

问题10：
状态：已修复 验收通过
现象：在客厅鱼缸内升级鱼灵时 一星升级到二星不会扣除鱼灵 可以利用分解无限刷
预期：不管在鱼灵哪里升级一颗星就会扣除一星鱼灵
根因/处理：已查看问题描述、截图、客户端 ArtifactStarUpDialog._onStarUp / ArtifactModule.sendUpgradeStar / 鱼缸入口链路、服务端 artifact_upgradestar / artifactx.HandleUpgradeStar 源码和 111111 当前服务端日志。截图中的客厅鱼缸详情页升星实际调用同一个 artifact_upgradestar 协议；服务端历史根因是一星升二星直接使用配置 starItemNum/Getyu 的数量，导致扣减口径和预期“一星升二星只扣 1 个一星鱼”不一致，鱼缸路径还可能以 heroId=-1 进入背包分支，已在服务端统一用 upgradeStarMaterialNeed 对一星升二星扣减钳制为 1，并在 heroId=-1 但鱼灵已装备时推断装备英雄走装备升星分支，避免生成背包里的高星鱼灵或少扣材料。2026-05-17 00:54-00:55 账号 111111 最新日志连续验证：11031->11032 回包 items.11031.quantity=28，随后 11032->11033 为 27，11033->11034 为 26，11034->11035 为 25，每次只扣 1 个 11031，且高星被装备到英雄、未额外生成背包高星鱼。该修复只收敛升星扣减口径，不做自动补/清物品。
验证：已跑 GOCACHE=/tmp/xianyu-go-build-cache go test ./internal/artifactx。
截图：

问题11：
状态：已修复 验收通过
现象：装备界面升级鱼灵后 客厅鱼缸内不同步显示
预期：装备界面升级和鱼缸内升级是同步的
截图：

问题12：
状态：已修复 验收通过
现象：鱼灵淬炼时每次增长都是0.2的往上增长
预期：词条数值增长全部随机 不应该是定死的 （每200-500次鱼珠随机一个属性会随机增长 3000-10000次可以洗出三红）
截图：

问题13：
状态：已修复 验收通过
现象：淬炼时锁定词条没用 还是会变换 切换页面就显示未锁定
预期：点击锁定后 本词条就处于锁定状态 不解锁永远不会变化
截图：

问题14：
状态：已修复 验收通过
现象：咸王梦境内 首次进入 未选择武将上阵 点击选择武将显示上阵武将以全部死亡 无法正常进行
预期：每次梦境开启首次进入玩家都可以自行选择5个武将上阵
截图：

问题15：
状态：已修复（待复测确认）
现象：怪异塔怪异寻宝内怪物拉倒相邻的位置会一直分化 退出游戏再进入后会消失
预期：拉到相邻的位置不会一直分化
截图：
根因/处理：已查看问题描述、截图、客户端 MergePlayTilesContainer._tryApplyItemDrop / MPData.canMergeItems / sendMergeItems、服务端 mergebox_mergeitem / mergebox.HandleMergeItem 源码和当前服务端日志。当前 server/logs/2026-05-17/protocol.log、app.log、security.log、gm_server.log 未找到 mergebox_* 现场请求；但代码链路可确定：服务端已经禁止相邻格合成并返回 code=1 msg=相邻位置不能合成，且不改棋盘状态；客户端却在发协议前只判断同 ID/可移动/可合成，没有判断相邻格，先本地执行 mergeItems 和合成动画，等服务端拒绝后再 _withdrawChanges 回滚，所以表现为相邻拖拽时反复“分化”，重进后按服务端状态恢复消失。已把同样的相邻格限制前置到客户端 MPData.canMergeItems，相邻格不再进入本地合成/动画/发起 mergebox_mergeitem，服务端拒绝仍保留作为兜底。

问题16：
状态：已修复 验收通过
现象:灯神挑战内灯神5赢了判定输
预期：赢了就是赢了 不会出现赢了判定输的情况
截图：

问题17：
状态：已修复 验收通过
现象：新号首次佩戴玩具点击使用无反应 无法正常佩戴
预期：所有账号所有玩具均可正常佩戴
截图：

问题18：
状态：已修复 验收完成
现象：排行榜内个人排行榜俱乐部排行榜显示为空
预期：正常显示排行榜内容
截图：

问题19：
状态：已修复 验收完成
现象：甄姬觉醒被动三后增加免控百分之50 不显示在面板
预期：武将被动觉醒后 属性增加会体现在面板上
截图：

问题21：
状态： 已修复 验收完成
现象：淬炼词条锁定后点击解锁输入密码点击确定无反应
预期：密码正确的情况下点击确定可以正常解锁
截图：

问题22：
状态：已修复 验收通过
现象：图鉴内典韦赵云最后一颗星级点击无法升级
预期：可以正常升满图鉴
截图：

根因/处理：已查看问题描述、两张截图、客户端 HeroBookPanel._refreshBookSlot / BookModule.bookLevelUp / BookService.upgrade 调用链、服务端 book_upgrade -> bookentry.HandleUpgrade -> growthbook.UpgradeHeroBook 源码和当前服务端日志。日志中账号 111111 在 2026-05-17 01:55 多次请求 book_upgrade {"heroId":117}，前面可正常升级，最后连续输出 图鉴已达最大等级: HeroId=117、book_upgrade_max_reload_retry_failed ... err=book max level；服务端代码在 nextIndex >= len(config.Star) 时返回最大等级。根因是服务端 server/runtime/data/book_config.json 与客户端 client/assets/config/config_ap.json 的图鉴配置不一致：客户端 BookConf 中 heroId=117/118/119/120 都是 31 星且最后一星点数为 3，服务端 117/118/120 只有 30 星、119 最后一星点数为 1，导致最后一颗星服务端判满级或加分口径错误。已补齐服务端 117/118/120 第 31 星，并把 119 最后一星点数修为 3；同时补充配置回归测试，全量比对客户端 BookConf 与服务端 book_config 的 hero 星级长度和最后一星点数已无差异。该修复只同步图鉴配置，不改武将升星、不扣物品、不做补偿。

问题23：
状态：已修复 验收通过
现象：鱼灵淬炼时 装配的洗练会出现相同的属性
预期：装配的淬炼不会出现同属性
根因/处理：已查看问题描述、截图、客户端 PearlStageUpDialog / NewPearlModule.sendGetRandomAttr / sendReplaceAttr / sendConfirmQuench、协议定义 PearlService.quench/replace/confirm、服务端 pearl_quench / pearl_replace / pearl_confirm / pearlx 源码和当前服务端日志。截图中鱼珠已装配槽位出现两个“破甲”。修复口径为服务端权威收敛：淬炼随机属性时通过 pickPearlAttrIDForQuench 优先避开已满 100 的属性；若随机命中已有属性，则 resolvePearlQuenchRoll 取同属性已有槽位的最大值叠加本次随机成长，并返回 matched slotIDs；确认/替换时 ReplaceFieldized 发现已有同 attrId 槽位后只更新这些已有槽位，不再选择新槽位生成第二条同属性。保留 pearl_quench duplicate_attr_detected 诊断日志，用于发现历史脏数据或旧版本已生成的重复槽位；该修复不自动删除玩家历史重复槽位，避免误删属性或引入补偿问题。
验证：已跑 GOCACHE=/tmp/xianyu-go-build-cache go test ./internal/gameplay/pearlx。
截图：

问题24：
状态：已修复 验收通过
现象：退出俱乐部在重新进入后 剩余的俱乐部军团币会清零
预期：换俱乐部 退出俱乐部俱乐部科技不会清理
根因/处理：已查看问题描述、截图、客户端 LegionResearchDialog / LegionResearchCostDialog / LegionResearchResetDialog / LegionModule、服务端 legion_leave -> legionmember.HandleLeave/Leave、HandleKickout、HandleDissolve、legion_getinfo 缺失军团自愈路径和当前服务端日志。截图中的右下角“当前拥有”读取的是客户端 ConstantConf.config.legionCoin 对应的物品 1014，科技等级读取 ROLE.legionResearch；当前日志里未找到本次 legion_leave 现场请求，但 server/logs/2026-05-17/protocol.log 中账号 13838384381 的回包可见 items.1014.quantity=5000000，且后续 legion_getinfo 存在返回 {} 的离团/无军团状态。服务端根因是军团成员领域层在离团状态变更时调用 ClearLegionCoin，主动退出、被踢、军团解散批量清成员、打开军团面板发现军团不存在/成员不存在的自愈路径都会把 items["1014"].quantity 置 0；legionResearch 本身未被清理。已移除这些离团/自愈路径对 1014 的清零，只保留解除 LegionId、成员关系、冷却和军团历史记录；同时补充/调整回归测试，覆盖主动退出、被踢、解散、军团缺失/成员缺失自愈时 1014 和 legionResearch 均保持不变。科技升级、签到发币、科技重置返还逻辑未改，避免引入少扣/超扣。
验证：已跑 GOCACHE=/tmp/xianyu-go-build-cache go test ./domains/legion/... 和 GOCACHE=/tmp/xianyu-go-build-cache go test . -run TestLegionBridge_UnitRules。
截图：

问题25：
状态：已修复 验收通过
现象：每日咸王可以无限挑战获取奖励且不记录最高伤害
预期：每人每天只能每个阶段奖励只能获取一次 且记录当天最高伤害
根因/处理：已查看问题描述、截图、客户端入口、服务端 fight_startboss / boss_getstate / boss_claimreward 链路和 2026-05-17 当前服务端日志。日志中 fight_startboss 已计算并打印 persisted-state，但后续 boss_getstate 仍 miss hurt=0，说明不是挑战次数或战斗结算问题，而是缓存状态未保住。根因是引入 RoleStore 缓存后，rolecachex fast path 未支持 bossFight.<bossId> 路径，且 internal/deepcopy.DeepCopyRoleManual 漏拷贝 Role.BossFight，导致 maxSingleDamage / totalDamage 和 claimedDamageReward 写入后在缓存读回、Get/flush 时丢失；客户端再次领取时服务端看到的已领奖励档位为空，所以当天同一档可重复领取。已补 bossFight 路径读写和 BossFightInfo 深拷贝，并增加回归测试覆盖 bossFight.9904 写入后最高伤害和 claimedDamageReward 都能从缓存字段读回。
验证：已跑 GOCACHE=/tmp/xianyu-go-build-cache go test ./internal/rolecachex ./internal/gameplay/bosschallengex ./internal/bosschallengeentry -count=1。
截图：

问题26：
状态：已修复 验收通过
现象：鱼灵升星后图鉴不会立马更新需要退出游戏重新进才会更新
预期：鱼灵升星后图鉴同步更新
根因/处理：已查看问题描述、截图、客户端 ArtifactModule.sendUpgradeStar、RoleDataView.updateValue/BookModule/HeroBookPanel 刷新链路、服务端 artifact_upgradestar 源码和 111111 当前服务端日志。日志显示 2026-05-17 00:37:28 账号 111111 升星回包带了 artifactBooks.1116.artifactId=11164，但同时错误带出 1000/2000/3700；客户端皮肤图鉴 _syncSkinBooks 对未知 key 有保护，鱼灵图鉴 _syncShowBooks 没保护，遇到这些客户端配置不存在的 key 会中断刷新。第一层服务端根因是 growth/book 用 id % 10 推断鱼灵星级，背包普通道具 10003/20008/37007 被误判成鱼灵图鉴；同时升星 handler 读缓存角色时会带历史脏 artifactBooks，即使后续 getOrCreateRole prune，回包仍使用旧对象。2026-05-17 00:46:17 再次查看 111111 最新日志，artifact_upgradestar 已正常返回 code/role/roleInfo 且英雄 artifactId=11162、物品 11161 已扣，但响应未带 artifactBooks；第二层根因是玩家背包仍有更高星 11165，升 11161 -> 11162 时图鉴最高记录不变，旧逻辑按“图鉴无变化”跳过下发，导致客户端不触发 SyncArtifactBooks 刷新。已改为必须命中 ArtifactConf 才参与鱼灵图鉴同步，并在升星同步前后清理无效 artifactBooks；同时鱼灵升星成功后，只要本次升星对应图鉴 key 存在，即使最高图鉴 ID 未变化也下发当前 artifactBooks/book 并额外主动推送真正的 syncresp（role/roleInfo），book 转为客户端字段名。该修复只改图鉴同步/回包，不改鱼灵升星扣物品逻辑，不自动增加图鉴点。
验证：已跑 GOCACHE=/tmp/xianyu-go-build-cache go test ./internal/artifactx ./domains/growth/book。
截图：

问题27：
状态：已修复 验收通过
现象：孙坚觉醒被动2后 不生效 普通攻击不扣除自身血量
预期：被动2觉醒正常生效
根因/处理：已查看问题描述、截图、客户端觉醒技能展示/点击逻辑、服务端 hero_skillawake/战斗队伍构造/技能归一化源码，以及当前服务端日志。截图中的技能是孙坚 heroId=115 的新版觉醒被动2 11506，新版配置 SkillSchemeConf[11506] 包含 115162，效果为 LOSE_CURRENT_LIFE(0.06,0,1)；但服务端觉醒接口读取的 config1/内嵌 HeroConf 仍是旧孙坚配置，觉醒被动写入旧 ID 1156，旧 SkillSchemeConf[1156] 只有改普攻目标的子技能 11561，没有扣自身当前血量效果，所以战斗中不扣血。修复为：getHeroDataByID(115) 返回与客户端/新版战斗配置一致的 11501/11505/11502-11504/11506-11508，避免新觉醒继续写旧 ID；同时补齐 skillutil.NormalizeSkillIDForHero115 的旧存档兼容映射 1156->11506、1157->11507、1158->11508，保证已有旧数据进入 battleData 时也会转成战斗服能识别的新版技能。
验证：已跑 GOCACHE=/tmp/xianyu-go-build-cache go test ./internal/skillutil ./domains/core/competitive -count=1、GOCACHE=/tmp/xianyu-go-build-cache go test ./internal/gameplay/battlex -run TestNormalizeAwakeSkinBattleData -count=1、GOCACHE=/tmp/xianyu-go-build-cache go test . -run TestGetHeroDataByID_SunJianUsesCurrentSkillIDs -count=1。
截图：

问题28：
状态：已修复 验收通过
现象：蓝玉红玉彩玉白玉等会出现变成负数的情况
预期：资源最小为0 不会有负数
根因/处理：已查看问题描述、截图、客户端资源展示、服务端装备淬炼/四圣淬炼/四圣升阶扣除路径、RoleStore patch 校验和当前服务端日志。修复口径不是“自动修正/归零”，而是服务端扣减前置库存校验 + RoleStore 全局负数拒绝：装备淬炼检查 1022 蓝玉、1023 彩玉，四圣淬炼检查 10002 四圣蓝玉，四圣升阶检查 10003 四圣红玉；所有通过 RoleFieldStore.ApplyPatch 的 items.<id>.quantity 负数增量都会在 rolecachex.validateItemQuantityIncrements 中按当前库存校验，若 cur+delta<0 直接返回 ErrInsufficientItemQuantity，不修改内存、不标 dirty、不落库。保留 [item_audit] 对 1022、1023、10002、10003、10004 的 old/new/delta/source 审计，用于后续定位非标准写入或历史脏数据。
验证：已跑 GOCACHE=/tmp/xianyu-go-build-cache go test ./internal/roleaudit ./internal/logswitch ./cache ./internal/rolecachex ./internal/gameplay/equipmentx ./internal/gameplay/hbx -count=1。
截图：

问题29：
状态:已修复 验收通过
现象：灯神挑战内扫荡卷可以一直领取 无上限
预期：没人一天最多领取三个
根因/处理：服务端 fieldized 领取逻辑读取 broad statistics，当前运行数据没有稳定返回嵌套统计，导致每日领取次数总按 0 判断。已改为精确读取 items.1021.quantity、statistics.genie:sweep:buy、statisticsTime.genie:sweep:buy，服务端按天限制最多 3 次。
验证：已补 server/internal/geniex/fieldized_test.go 并跑定向测试。
截图：

问题30：
状态：已修复 验收通过
现象：个别号灵珠技能界面显示为空 无法佩戴 无法兑换（账号：asd110 密码：900324）
预期：所有账号都正常显示 （如截图2）
根因/处理：已查看问题描述、两张截图、客户端 PearlBagDialog / NewPearlModule.getBagList / findSkillHolder / PearlDataView、服务端灵珠技能购买/装配/交换/卸下/登录回包源码，以及当前服务端日志。当前本地日志和当前 Mongo 未找到账号 asd110 / 截图角色 289911 的现场记录；按截图和代码链路定位到服务端数据契约问题：客户端技能包遍历 ROLE.pearlMap[*].skillId 时假设带技能的灵珠一定有有效 artifactId，会调用 ItemConf.getById(artifactId).name；服务端历史/缓存数据可能留下 skillId > 0 但 artifactId <= 0 的灵珠，登录回包只归一化 tmpSlot，没有修复这类脏灵珠，导致个别号打开技能包时列表构造中断，表现为整页空白，后续佩戴/兑换入口也不可用。已在服务端登录/构建角色回包前增加修复：能从已装备英雄的 pearlId -> artifactId 反推时补齐 pearlMap.artifactId；反推不了的孤立技能不丢弃，迁回 pearlSkillStorage 并清空该灵珠 skillId，让客户端按“未装配技能”正常展示和佩戴。
验证：已补 TestRepairRoleInvalidPearlSkillHolders_FillsArtifactFromEquippedHero、TestRepairRoleInvalidPearlSkillHolders_MigratesUnattachedSkillToStorage，并跑 GOCACHE=/tmp/xianyu-go-build-cache go test . -run 'Test(RepairRoleInvalidPearlSkillHolders|PrepareRoleForRoleGetRoleInfo_RepairsMissingLord)' -count=1、GOCACHE=/tmp/xianyu-go-build-cache go test ./internal/gameplay/pearlx -count=1。
截图：

问题31：
状态：已修复 验收通过
现象：武将面板属性会莫名变的很低 需要动一下关于战力的东西才会恢复
预期：面板属性永远根据现在武将的各种加成而定 不会忽然变低
根因/处理：已查看问题描述、4 张阵容详情截图、客户端 SpecificsTeamDialog / RoleDataView / HeroDataView、服务端 Getrole / GetroleBonusCached / GetRoleBonusWithOriginalRoleForHeroAndBattleTeam / bonusviewx 计算链路，以及当前 server/logs/2026-05-17/rolepower.log、rolestore.log、app.log。截图中同一阵容英雄从攻击/血量只有基础低值，变为带完整动态加成的高值；客户端阵容详情不单独请求服务端，直接读本地 ROLE.heroes.<heroId>.attack/hp/defense/power，所以根因只能是服务端回包曾把未加成的原始英雄属性合并进客户端。服务端根因是新 bonus 缓存拆成轻量 CalculatedBonus 后，单英雄/局部刷新会把“当前英雄 + battleTeam”的局部 bonus 写入全局缓存；但 Getrole 全量角色展示/登录回包直接复用 GetroleBonusCached，没有校验该 bonus 是否覆盖角色所有英雄，导致未覆盖英雄保留 RoleStore 原始属性下发，面板显示变低。后续任意战力相关操作重新计算对应英雄后，面板又恢复。已改为 Getrole 全量入口只接受覆盖全部英雄的 bonus；若命中局部 bonus，记录 role_bonus_cache_skip_partial 并走全量重算，不回退局部缓存。
验证：已跑 GOCACHE=/tmp/xianyu-go-build-cache go test . -run 'Test(SyncRolePowerFromCalculatedRole|CalculatedBonusCoversAllRoleHeroes)' -count=1、GOCACHE=/tmp/xianyu-go-build-cache go test ./internal/bonuscalcx ./internal/bonusviewx -count=1。
截图：

问题32：
状态：已修复 验收通过
现象：游戏内切换玩具后 所有玩具的被动2被动3加成不会立马加成到武将身上 面板不会显示 需要退出游戏在进入才会更新
预期：玩具切换后 玩具被动立马加成到武将身上且凸显在面板上
根因/处理：已查看问题描述、截图、客户端 WeaponModule.sendChangeDefaultWeapon / WeaponEquipConfirmDialog / WeaponUnloadConfirmDialog、服务端 LordweaponChangeDefaultFieldized / buildHeroesDataFromBonus / lordweapongrowth.LoadAttrs / getOrCreateRole / GetroleOld / 排行榜详情属性计算，以及 2026-05-20 账号 123456 服务端 protocol.log、rolepower.log、security.log。历史根因是 6 号玩具冰镇啤酒的被动2/3 映射错误读取 5 号玩具 18/19，已修为 22/23；今天新日志显示验收主角色 roleId=215046 在 13:26、15:04 多次 lordweapon_changedefaultweapon/lordweapon_exchange，服务端已重算 role.heroes 的攻击/血量/战力并回包，说明被动计算链路已生效。但回包构造 buildHeroesDataFromBonus 只返回 attack/defense/hp/speed/power，没有返回客户端武将属性面板读取的 attribute 字段；截图里的“特殊属性”就是 attribute 中的增伤、破甲、格挡等百分比属性，所以客户端切换玩具后基础数值能更新，特殊属性仍保留旧值，退出重进后全量 role_getroleinfo 才刷新。已在玩具切换/升级回包的英雄数据中补齐 attribute: calculatedHero.Attribute，确保被动2/3 的特殊属性立即同步到面板。
验证：已补 TestBuildHeroesDataFromBonus_IncludesCalculatedAttribute 覆盖玩具重算回包必须携带计算后的 attribute；已跑 GOCACHE=/tmp/xianyu-go-build-cache go test . -run 'TestBuildHeroesDataFromBonus_IncludesCalculatedAttribute|Test(SafeLordWeaponPassiveSkill|CalculateTotalSkillAttributes|CalculatedBonusCoversAllRoleHeroes)' -count=1、GOCACHE=/tmp/xianyu-go-build-cache go test ./domains/growth/lordweapon ./internal/gameplay/rankx -count=1、GOCACHE=/tmp/xianyu-go-build-cache go test ./internal/gameplay/lordweaponx -run 'TestLordweapon(ChangeDefault|UpgradePassive|Exchange)' -count=1。
截图：

问题33：
状态：已修复 验收通过
现象：游戏内限时活动内单周活动红淬达标活动达标后点击领取无反应
预期：达标后可以正常领取奖励
根因/处理：服务端周活动 13 的红淬达标配置与客户端 QuenchRewardConf 口径不一致，奖励列表类型兼容不足，且红淬统计未稳定同步。已在 server/internal/activity/claimbridge/handlers.go 增加红淬达标兜底档位、奖励列表 map/list 兼容和 wa:q:rd 同步；同时跳过 type=3 且 itemId<=0 的异常奖励，避免写出 items.0.quantity。
验证：已补 server/internal/activity/claimbridge/handlers_test.go 并跑定向测试。
截图：

问题34：
状态：已修复 验收通过
现象：吕布佩戴四圣皮肤后再除主线关卡外的任何战斗鱼灵月光都不生效
预期：任何英雄任何皮肤不影响鱼灵的功能
根因/处理：已查看问题描述、截图、客户端鱼灵/出战数据读取、服务端战斗数据组装与当前服务端日志。截图显示吕布佩戴四圣皮肤 10711 且装备满星月光；客户端鱼灵展示和出战数据按 artifactId/pearlId 独立于皮肤处理，战斗响应读取的是 battleData.leftTeam.team[*].skill。服务端根因在 NormalizeAwakeSkinBattleData：吕布四圣皮肤归一化时直接把 skill 覆盖为 [206,207,208]，导致此前由 getArtifactPassiveSkillIDs 加入的月光被动 11105 以及其他外部技能丢失，非主线外部战斗进入战斗服时月光不生效。已改为只替换吕布自身 201-208 技能，保留鱼灵/珍珠等外部技能，再追加四圣斩杀技能。
验证：已补 server/internal/gameplay/battlex/normalize_test.go 回归用例，覆盖吕布四圣皮肤保留月光 11105/珍珠技能、替换旧吕布技能并追加 213/215；已跑 GOCACHE=/tmp/xianyu-go-build-cache go test ./internal/gameplay/battlex -run TestNormalizeAwakeSkinBattleData -count=1。
截图：

问题35
状态：已修复 验收通过
现象：锁定淬炼时必须设置淬炼密码
预期：设不设置密码是玩家的自由 无需必须设置
根因/处理：已查看问题描述、截图、客户端 QuenchStageUpDialog._onClickLockBtn / EquipmentModule.sendUpdateQuenchLock、服务端 equipment_updatequenchlock / passwordx 源码和当前服务端日志。截图文案“请先设置淬炼安全锁密码”来自服务端 passwordx.CheckQuenchPasswordSet；客户端锁定按钮没有本地强制密码拦截，会直接发送 equipment_updatequenchlock {isLocked:true}。服务端根因是在装备淬炼“上锁”分支先校验必须设置淬炼安全锁密码，和预期“密码可选”冲突。已改为装备淬炼上锁不要求密码，解锁仍保留 CheckQuenchAccess：未设置密码时可自由解锁，已设置密码且未验证时仍要求密码，避免安全锁语义倒退。当前 server/logs/2026-05-17/protocol.log、app.log、gm_server.log 未找到 equipment_updatequenchlock 现场请求；本次按截图文案与服务端确定性源码根因修复。
验证：已跑 GOCACHE=/tmp/xianyu-go-build-cache go test . -run 'Test(CheckEquipmentQuenchLockAccess|BuildEquipmentQuenchLockRoleDelta)'。
截图:

问题36：
状态：已修复 验收通过
现象：四圣等级升级时共鸣加成加到了面板 突破加成没加到面板上
预期：每次突破等级的加成正常加到武将身上 显示在面板上
根因/处理：已查看问题描述、三张截图、客户端 HolyBeastSkinDialog / HBSkinBreakPanel / 面板属性读取逻辑、服务端 hbx.UpgradeOrderFieldized / ComputeMergedHeroResponse / BonusCalculator.calculateHeroBonus / Getrole 计算链，以及当前服务端日志。截图里的“共鸣加成”来自角色 hB.attack/hp/speed，突破弹窗展示的是 HolyBeastOrderConf.orderAttr 的 type=5 攻击百分比、type=7 血量百分比；客户端升级后只合并服务端回包 role.heroes，面板不在本地重算属性。服务端根因是四圣突破升级只写入并计算了 hB.attack/hp/speed 共鸣平铺值，权威属性计算没有读取 HolyBeastOrderConf.orderAttr，所以突破百分比配置只在突破界面可见，没有进武将面板属性。已在服务端英雄属性权威计算链补入四圣突破 orderAttr 攻击/血量百分比，并覆盖缓存计算、直接 Getrole 计算和指定阵容计算路径。
验证：已补 TestHolyBeastOrderAttributeBonus_ReadsBreakthroughConfig、TestCalculateHeroBonus_AppliesHolyBeastOrderAttr，并跑 GOCACHE=/tmp/xianyu-go-build-cache go test . -run 'Test(HolyBeastOrderAttributeBonus|CalculateHeroBonus_AppliesHolyBeastOrderAttr)' -count=1、GOCACHE=/tmp/xianyu-go-build-cache go test ./internal/gameplay/hbx -run TestUpgradeOrderFieldized_UpgradesOneOrderPerRequest -count=1。
截图：

问题37:
状态：已修复 验收通过
现象：俱乐部内和排行榜内俱乐部详情里 俱乐部成员战力红淬显示不对
预期：正常显示当前成员上阵的战力和红淬数量
根因/处理：已查看问题描述、三张截图、客户端 LegionDetailsDialog / LegionMembersDialog 字段绑定、服务端 legion_getinfo / legion_getinfobyid 源码和当前服务端日志。客户端显示的就是服务端成员 power 与 custom.battle_red_quench_cnt；服务端 legion_getinfo 未传红淬解析器，导致成员红淬固定为 0；成员战力解析又在军团成员快照 member.Power > 0 时直接返回快照，旧快照正数会绕过当前角色战力。已改为俱乐部内页和排行榜俱乐部详情均读取当前角色战力和当前上阵红淬，角色缺失时才兜底快照。
验证：已补 TestHandleGetInfo_UsesResolversForMemberPowerAndRedQuench，并跑 go test ./domains/legion/read 定向用例。
截图：

问题38：
状态：已修复 验收通过
现象：金鱼协力公 协力母 不生效（账号 facai888密码facai888）
预期：两种协力武将佩戴出战时正常生效
根因/处理：已查看问题描述、截图、客户端鱼灵/战斗展示逻辑、服务端战斗组装和当前 2026-05-18/19/20 服务端日志。截图中的协力♂/♀对应鱼灵 11081-11085、11091-11095，客户端和 server/config/config.json 的 ArtifactConf.passiveSkill 与 SkillSchemeConf 均有配置；服务端 buildLeftTeam -> extractActiveSkillIDs -> getArtifactPassiveSkillIDs 会把鱼灵被动方案 ID 写入 battleData.leftTeam.team[*].skill。根因是运行时热加载文件 server/config/SkillSchemeConf.json 缺少协力鱼灵 11081-11085/11091-11095 方案，战斗侧按运行时 SkillScheme 查不到方案，导致协同攻击/回复/暴伤效果不生效。当前日志未找到 facai888 的同窗口战斗 trace，但可见服务端多次加载运行时 SkillSchemeConf 与鱼灵配置，且有 11081 购买/升星行为；该问题由运行时配置缺失可确定复现。已补齐运行时 SkillSchemeConf 中两组协力鱼灵 10 条方案。
验证：已补 TestRuntimeSkillSchemeFileContainsCooperationFishRows 和 TestBuildLeftTeam_IntegrationIncludesCooperationFishPassiveSkill，并跑定向 Go 测试通过。
截图：

问题39：
状态：已修复 验收通过
现象：武将被赐福后 在竞技场和灯神挑战内赐福不生效
预期：赐福后 在任何副本战斗中都可以正常生效
根因/处理：已查看问题描述、截图、客户端赐福/竞技场/灯神挑战入口、服务端 equipment_enchant / arena_startarea / fight_startgenie / 战斗组装源码和 2026-05-20 账号 123456 服务端日志。验收账号主角色为 roleId=215046；日志显示 equipment_enchant 已保存 105->106 赐福映射并在普通战斗加成链路生效，但紧接着 arena_startareaHandler 触发非赐福保存保护逻辑时打印“保留最新赐福映射 mapSize=0”，把内存里刚写入、尚未异步落 Mongo 的 enchantMap 用 Mongo 旧空值覆盖，导致竞技场/灯神挑战战斗读取不到赐福。已把 GetLatestEnchantMap 改为优先从 RoleStore 内存字段读取最新 enchantMap，Mongo 只作为冷数据兜底，避免刚赐福后立即进副本被旧持久化状态回滚。
验证：已补 TestRoleStore_GetFieldsReturnsLatestEnchantMapAfterReplace 覆盖角色缓存字段读取最新赐福映射；已跑 GOCACHE=/tmp/xianyu-go-build-cache go test ./internal/rolecachex -run 'TestRoleStore_(ReplacePreservesCargoRaidState|GetFieldsReturnsLatestEnchantMapAfterReplace|GetReturnsDeepCopy)' -count=1、GOCACHE=/tmp/xianyu-go-build-cache go test . -run 'Test(Arena|FightStartArea|EquipmentEnchant|BuildLeftTeam_IntegrationIncludesCooperationFishPassiveSkill)' -count=1。
截图：

问题40：
状态：已修复 验收通过
现象：手动关闭武将赐福后 退出游戏重新进入或者去打一把竞技场 自动又恢复原本的赐福状态了
预期：赐福关闭后除非玩家手动进行开启赐福 不然永远不会自动恢复、
截图：

问题41：
状态：已修复 验收通过
现象：竞技场内所有人在一个组
预期：每个场次每组最大为100人
匹配规则：
每次最多匹配 4 人
只能匹配 ±200 分以内 的对手
不满意可 刷新：首次免费，后续金砖

升降级（每周日 24:00 结算）：
入门级：前30晋级，其余平级
初级：前20晋级，后10降级
中级：前30晋级，后30降级
高级：前20晋级，后40降级
大师级：前20晋级，后80降级
巅峰级：无晋级，后80降级
根因/处理：已查看问题描述、截图、客户端 ArenaPanel/ArenaModule/ArenaBattleDialog、服务端 arena_getarearank/arena_getareatarget 源码和 2026-05-18/19/20 当前服务端日志。日志中 arena_getarearank 回包直接返回全局榜 rank/total，客户端又直接展示该 rank，并用 total 计算升降级人数，导致截图中出现 2113 名这种“全服一个组”的效果。服务端已按当前玩家全局排名切 100 人小组，返回本组本地 rank、total 最大 100，同时保留 globalRank/globalTotal 便于排查；匹配候选改为最多 4 人，并移除无候选时扩大到 ±200 分以外的回退；刷新匹配补上服务端首刷免费、后续按 ArenaRefreshConf 扣金砖并同步 statistics/statisticsTime。
验证：已补 TestArenaRankGroupHelpers_LocalizeGlobalRank、TestArenaGetAreaTarget_IntegrationCapsOpponentListAtFour、TestArenaGetAreaTarget_RefreshCostUsesFirstFreeThenDiamond，并跑竞技场相关定向 Go 测试通过；go test ./... 仍有既存非本次改动失败项，已记录。
截图：

问题42：
状态：已修复 验收通过
现象：开启钻石宝箱加积分
预期：钻石宝箱不会加积分
根因/处理：当前日志已确认 item_openbox itemId=2005 回包包含 boxPoint:100；服务端 server/internal/systemx/store_tower_item.go 对钻石宝箱配置了积分。已将钻石宝箱积分改为 0，并在积分 delta 为 0 时跳过周活动积分更新。
验证：已补 TestItemOpenBoxFieldized_DiamondBoxDoesNotAddWeeklyPoints 并跑定向测试。
截图：

问题43：
状态：已修复 验收通过
现象：典韦四圣升级后被动加成不生效 面板不显示
预期：被动加成正常生效且显示在面板
根因/处理：已查看问题描述、截图、客户端四圣展示、服务端四圣升级/属性合并逻辑和当前服务端日志。根因是客户端配置已有典韦四圣技能 161-170，其中 161/165 对应“逐虎过涧”破甲抵抗 7%-35%，但服务端 server/config/HolyBeastSkillConf.json 只到 160；典韦四圣解锁/升级后服务端存 161/166 等配置 ID，属性计算 GetHBSkillAttrs 查不到配置，所以面板和战斗属性都不会加。已补齐服务端典韦四圣技能配置 161-170，与客户端一致。
验证：已跑四圣相关定向 Go 测试。
截图：

问题44：
状态：已修复 验收通过
现象：玩具被动只有解锁被动后 上阵武将星级不满 玩具被动不解锁
预期：玩具被动只有首次解锁需要达到对应要求 解锁后不管上阵武将多少星级 玩具被动都正常生效 无需必须达到对应星级
根因/处理：服务端 lordweapon_get 会按“当前上阵总星级”过滤已存在被动，并把低于当前星级门槛的已解锁被动 Unset 掉；升级被动时也重复要求当前上阵星级。截图中“当前60星”导致已解锁被动显示锁定，与源码根因一致。已改为：已存在的 passiveSkill 代表已经解锁，get/升级/回包 不再按当前阵容星级隐藏或删除；只有自动创建缺失的下一被动时仍要求首次解锁星级门槛。
验证：已补/改 server/internal/gameplay/lordweaponx/fieldized_test.go，并跑 go test ./internal/gameplay/lordweaponx ./internal/logswitch。
截图：

问题45：
状态：已修复 验收通过
现象：梦魇水晶内双攻水晶 破甲水晶 精准水晶 暴击爆伤水晶里的百分比攻击加成不生效
预期：这四个水晶里的百分比攻击正常加成生效
根因/处理：已查看问题描述、四张水晶转换截图、客户端 TrumpStageUpDialog/EquipmentModule、服务端水晶属性读取/角色面板/好友排行详情源码和当前 2026-05-18/19/20 服务端日志。截图右上角 289911/dev28 不是账号；日志中也未检索到它作为 account/roleId 出现，当前可关联的真实账号只能来自协议日志里的 account=... roleId=...。客户端展示的是 TrumpConf.trumpAttr，双攻/破甲/精准/暴击爆伤水晶都包含 type=5 攻击百分比；服务端 trump.LoadCoreAttrs 已能读取 type=5，但 BonusCalculator.calculateHeroBonus、旧 role_getroleinfo 分支、rankx.BuildRoleInfoResponseFromRole 只把 type=1 固定攻击纳入最终攻击，漏掉 type=5 百分比攻击，导致面板/详情路径看起来百分比不生效。已在三条服务端计算入口统一叠加水晶 type=5 攻击百分比。
验证：已补 TestCalculateHeroBonus_AppliesTrumpAttackPct 单测和 TestBuildRoleInfoResponseFromRole_AppliesTrumpAttackPct 集成路径测试，并跑定向 Go 测试通过。
截图：

问题46：
状态：已修复 验收通过
现象：灯神挑战内 灯神9-10-11-12boss伤害不对 每次只能造成1点伤害 且很多关卡存在赢了判输的情况
预期：每个国家所有关卡boss伤害正常 不会存在赢了判定输
根因/处理：已查看问题描述、截图、客户端 GenieModule/GenieShopInner/NewGenieLevelTeamDialog、服务端 geniex 灯神战斗组装/配置加载/战斗回退源码和当前 2026-05-19/20 服务端日志。截图右上角 289911/dev28 不是账号；当前日志中可检索到真实 fight_startgenie 账号如 biao12/68320，并有外部战斗服务超时后回退 Go 引擎、深海灯神失败审计日志。根因是服务端 GetGenieLevelConfig 只读 config_ap1.genieLevelConf，当前项目配置缺失普通灯神关卡数据时，buildGenieRightTeam 会退化成单只假怪并按 关卡*50000 计算战力，9-12 关 boss 攻击只有数百，战斗公式被钳到最小 1 点伤害；配置缺失路径也会放大战斗服务/本地回退结果差异。已在普通灯神配置缺失时改为使用现有 MonsterConf 的国家怪 7101-7403 和 LevelCoeffConf 的 301-317 系数生成三只配置怪，并记录缺失配置降级日志；已有本地战斗复核和 HP 领先修正继续防止“赢了判输”。
验证：已补 TestBuildGenieRightTeam_FallbackNormalLevelsUseLevelCoeff 单测和 TestBuildGenieBattleDataWithResult_IntegrationNormalGenieFallbackBossAttrs 集成路径测试；go test ./internal/geniex -count=1 通过。
截图：

问题47：
状态：已修复 验收通过
现象：淬炼时每次淬炼加成血量过低 导致孔位开完完血量还没加满 开完五孔会直接加满
预期：铠甲 / 坐骑：每次 +27基础血 最大
根因/处理：已查看问题描述、坐骑淬炼截图、客户端 EquipmentModule/QuenchStageUpDialog 淬炼请求和展示逻辑、服务端 equipment_quench 前后面淬炼源码、quench_prob 配置及当前 2026-05-20 服务端日志。截图右上角 289911/dev28 不是账号；当前日志中可见真实 equipment_quench trace 如 account=123456 roleId=163853。根因是服务端铠甲/坐骑永久血量加成走 equipmentQuenchExtra.hp 随机区间 5-24，且复用攻击/防御的成功判定，导致单次可能只加 10 点甚至不加；第 5 孔在 QuenchTimes>=10000 时又被服务端直接套上满值，所以表现为“前面加得低，开五孔直接加满”。已将铠甲/坐骑 HP 永久加成改为每次固定 +27，前面/反面淬炼都走同一固定 HP 入口，并保留铠甲 198972、坐骑 183666 上限；攻击/防御随机加成逻辑不变。
验证：已补 TestDefaultConfigKeepsCurrentExtraPetAndHBDefaults 中 HP 固定值校验、TestSetupQuenchSlots_AddsFixedHPExtraForArmorAndMount、TestSetupBackQuenchSlots_AddsFixedHPExtraForArmorAndMount 集成路径测试；定向 go test ./internal/gameplay/quenchprob . 通过。
截图：

问题48：
状态：已修复 验收通过
现象：武将被赐福后 使用无损换将 那么这套赐福就不会在生效 换一个将使用也不会生效了
预期：无损换将后赐福依旧生效 赐福给谁都可以正常生效 不会存在无损换将后这套淬炼赐福失效
截图：

问题49
状态：已修复 验收通过
现象：武将鲁肃被动4觉醒技能不生效 灼烧免疫100加成不生效
预期：觉醒技能加成正常生效
根因/处理：已查看问题描述、鲁肃觉醒技能截图、客户端技能展示配置、服务端 SkillSchemeConf 运行时加载/属性汇总源码和当前 2026-05-20 服务端日志。截图右上角 289911/dev28 不是账号；当前日志未找到该截图账号，只能从现有 role_getroleinfo/fight_startlevel trace 辅助确认服务端配置路径。完整配置 server/config/config.json 中鲁肃觉醒被动4 1218 正确包含 attrs: [{type:70,value:1}]，但运行时热加载文件 server/config/SkillSchemeConf.json 缺少鲁肃 1211-1218，且 1216 还是错误的“指囷相赠”内容。服务端技能属性管理器优先读取运行时文件，导致鲁肃满觉被动4的灼烧免疫没有进入面板/战斗属性。已从完整配置同步鲁肃 1211-1218 到运行时 SkillSchemeConf.json。
验证：已补/扩展 TestRuntimeSkillSchemeFileContainsAwakeSkillRows，并新增 TestLoadRuntimeSkillScheme_LusuAwakeBurnImmunity 覆盖运行时文件经技能管理器加载后 1218 能返回 type=70,value=1；定向 go test ./internal/gameplay/herox ./internal/skillscheme 通过。
截图：

问题49：
状态：已修复 验收通过
现象：武将黄玉英被动3觉醒技能不生效 加成不到面板 和诸葛一起上场会在诸葛之前死亡
预期：被动3正常生效 且加成正常加成显示在面板
截图：

问题50：
状态：已修复 验收通过
现象：武将孙坚被动3觉醒后不生效 加成不到面板
预期：被动三觉醒后正常生效 加成正常加到面板
截图：

问题51：
状态：已修复 验收通过
现象：玩具冰镇啤酒被动2被动3加成不生效 不显示在武将面板
预期：玩具被动加成正常生效且体现在武将面板
根因/处理：同问题32。已查看该问题描述、截图、客户端玩具切换入口、服务端玩具切换/属性计算源码和当前服务端日志；截图明确为冰镇啤酒，服务端 6 号玩具被动2/3 映射错误读取 18/19，实际应读取 22/23，导致服务端回包和战斗属性都拿不到冰镇啤酒被动2/3 加成。已统一修正服务端 6 号玩具属性映射。
验证：同问题32。
截图：

问题52:
状态：已修复 验收通过
现象：对战房间标准房间内 设置阵容时武将战力显示不对 为负数
预期：正常显示玩家当前预设阵容的正确战力值
根因/处理：已查看问题描述、两张截图、客户端 RoomFightOfficialDeployDataAdapter / RoomFightRingData 字段绑定、服务端 pkroom_calcteam / pkroom_setfightroomteam 源码和当前 pvp/protocol 日志。客户端布阵页直接显示服务端 teamPower/teamHp；服务端 PK 房间队伍汇总用平台相关的 int 累加英雄 int64 战力和血量，超过 32 位有符号范围时存在变负风险，截图中的负战力/负 HP 与该溢出模式一致。已将 PK 房间队伍汇总改为 int64 全链路返回。
验证：已补 TestBuildPKTeamSummary_DoesNotOverflowInt32Range，并跑服务端定向测试。
截图：

问题53：
状态：已修复（验收通过
现象：咸将塔内没通过10关奖励的小鱼干 不到账
预期：奖励的鱼干正常到账
根因：购买能到账是因为 tower_buyenergy 直接累加客户端顶部读取的 tower.energy；客户端第 10/20/30 层胜利时先用本地塔配置展示“小鱼干X10”，再刷新 tower_getinfo。13838384381 的日志证明：手动打完第 10 层后没有发送 tower_claimreward，所以服务端必须在 fight_starttower 胜利结算时写入 tower.energy。后续验证又发现重复发放：18:18:17 第 10 层后 tower_getinfo energy=11，说明战斗胜利已补 10；18:18:29 tower_claimreward 又返回 {type:9,itemId:9,value:10}，随后 tower_getinfo energy=21。20/30/40 层同样在战斗胜利和领奖各加一次，根因是 tower_claimreward 仍保留额外拼小鱼干的补丁。
修复：第 10/20/30… 层小鱼干只由 fight_starttower 胜利结算发放一次，直接 tower.energy += 10 并在战斗回包奖励里返回 {type:9,itemId:9,value:10}；tower_claimreward 改回只按 TowerReward 配置发宝箱奖励，不再额外注入小鱼干，避免战斗奖励和领奖奖励重复。
验证：已补 TestFightStartTowerFieldized_FloorTenGrantsDryFishEnergyOnly、TestGetTowerRewardItems_DoesNotInjectDryFishBonus，并跑服务端定向测试。
截图：

问题54：
状态：已修复 验收通过
现象：俱乐部成员签到后不计入盐场报名条件内
预期：每个成员签到都计入盐场报名条件内
根因：客户端盐场报名条件读俱乐部 statistics["week:sign:in"]，盐场报名服务端也用 legion.Statistics.WeekSignIn 校验；但服务端签到 ApplySignIn 只更新 sign:in 和成员 SignInTime，没有维护周累计签到次数。
修复：签到成功时按 GMT+8 ISO 周维护 week:sign:in 和时间；对已签到但周统计缺失的旧数据按成员本周签到时间补齐最低值；legion_getinfo 展示和盐场报名校验前统一使用该修复口径。
验证：已补/更新 ApplySignIn、ReconcileWeekSignIn 相关测试，并跑 legion/member、legion/read、legion/war/saltfield 定向测试。
截图：

问题55：
状态：已修复 验收通过
现象：梦魇水晶点击翻面显示服务器走神 多次点击开启后 再次点击还是重复开启界面
预期：点击一次可正常开启翻面
根因：第一段根因是客户端解锁第二套梦魇水晶后只判断协议 code，实际界面状态继续读全局 ROLE.heroes[heroId].trumpId2；服务端 trump_unlock2 字段化路径虽然写入了 trumpId2/transTrumpId2 并在普通回包返回 role，但没有像 trump_change/trump_transsave 一样推 syncresp，客户端本地 ROLE 没刷新，所以再次点击仍按未解锁弹确认框。验收新日志 668529-13838384381-439-trump_change 的根因是新引入的 RoleStore.ApplyPatchWithSource 会直接修改调用方传入的 patch.Set map，补入 updatedAt/updatedAtNs；trump_change 的 applyTrumpFlipPatch 复用同一个 setOps 构造英雄回包，并假设所有 key 都是 heroes.<heroId>.<field>，遇到被 rolecache 污染出的根字段 updatedAt 时执行切片，触发 slice bounds out of range [11:9]，所以客户端看到“服务器似乎走神了”。
修复：trump_unlock2 成功后补推 syncresp，同步 heroes[heroId].trumpId2/transTrumpId2 到客户端全局 ROLE；同时把客户端配置里的 20000 金砖解锁成本补到服务端校验和落库。验收失败的 panic 已从根上修复 rolecache：ApplyPatchWithSource 先复制调用方 Set，再追加内部 updatedAt/updatedAtNs，保证 rolecache 不污染业务侧的 setOps。
验证：已补 TrumpUnlock2Fieldized 定向测试，覆盖首次解锁初始化背面水晶、扣 20000 金砖、资源不足不落库；本次补 TestRoleStore_ApplyPatchDoesNotMutateCallerSet 锁定 rolecache 不修改调用方 Set 的契约，并跑 GOCACHE=/tmp/xianyu-go-build-cache go test ./internal/rolecachex -run 'TestRoleStore_ApplyPatch(UpdatesMemoryAndDirtyStats|DoesNotMutateCallerSet)' -count=1、GOCACHE=/tmp/xianyu-go-build-cache go test ./internal/trumpx -run 'TestTrump(Change|Unlock2)' -count=1。
截图：

问题56：
状态：已修复 验收通过
现象：如下方截图 武将周瑜有红色淬炼 武将大乔没有 使用无损换将后 大乔和周瑜互换淬炼 大乔继承了周瑜原有淬炼 周瑜应该继承大乔的 但是周瑜却还是有原本的淬炼 退出游戏再进后会消失
预期：无损换将后两个武将的淬炼会互换 不会出现这种情况
根因：客户端无损换将只调用 HeroService.exchange，成功后依赖服务端回包里的 role.heroes 合并刷新英雄装备/淬炼状态；旧服务端换将路径只做局部差异回包，且装备槽位交换/重建时没有强制把参与换将的两边英雄完整写入回包，导致客户端本地还残留原英雄淬炼，看起来“退出游戏再进后消失”。这不是单纯客户端显示问题，服务端协议回包必须把两边英雄装备淬炼状态同步完整。
修复：当前服务端 hero_exchange 已按装备槽位并集深拷贝交换装备，按装备等级清理未解锁淬炼状态，换将后强制将参与换将英雄和阵上英雄写入 role.heroes 回包，并补 privilege 触发客户端装备模块刷新；同时保留 hero_exchange[before_exchange/normalize_exchange_equipment/before_response/response_summary] 日志用于验证淬炼流向。
验证：已查看截图、客户端 HeroExchangeDialog.onClickYes、服务端 herox.HandleExchange / finalizeHeroExchangeResponse 和当前 2026-05-17 服务端 hero_exchange 日志。日志中 668529-13838384381-41-hero_exchange 显示 109 的 4000 级红淬装备在 normalize_exchange_equipment 后移动到 118，109 变为 1 级无淬炼，response_summary 回包也一致；已跑 GOCACHE=/tmp/xianyu-go-build-cache go test ./internal/gameplay/herox -run 'TestHandleExchange' -count=1。
截图：

问题57：
状态：已修复 验收通过
现象：咸将塔内倒计时不会倒计时
预期：小鱼干不足10个时会进行倒计时 计时结束会获取一个小鱼干 最大剩余10
截图：
根因：截图中咸将塔右上角小鱼干为 0/10 且倒计时停在 00:00。客户端 TowerMainPanel.resetTimer 每秒按 ROLE.tower.energyRecoveryTime + ConstantConf.towerEnergyUp - serverTime 显示倒计时，到点后调用 TowerModule.refreshTowerEnergyInfo -> tower_getinfo 刷新；服务端 tower_getinfo 只原样返回 tower.energy/energyRecoveryTime，没有按时间结算恢复，因此倒计时到 0 后服务端仍返回旧体力，客户端无法获得新小鱼干。
修复：在服务端 internal/gameplay/towerx 增加咸将塔体力恢复结算，tower_getinfo 返回前按 towerEnergyUp=1800 秒恢复小鱼干并最多结算到 towerEnergyMax=10，未满体力且缺少恢复起点时补起点，满体力时清理恢复计时；桥接层从 ConstantConf 读取恢复间隔和上限。
验证：已查看截图、客户端 TowerMainPanel.js/TowerModule.js、服务端 compat_fieldized_bridge.go/internal/gameplay/towerx/start.go、当前服务端日志 server/logs/2026-05-19 中 tower_getinfo/fight_starttower 请求链。单测/集成测试通过：GOCACHE=/tmp/xianyu-go-build-cache go test ./internal/gameplay/towerx -count=1，GOCACHE=/tmp/xianyu-go-build-cache go test . -run 'TestGetTowerRewardItems_DoesNotInjectDryFishBonus|TestBuildMessageHandlers_RegistersEvoTowerCommands' -count=1。

问题58：
状态：已修复 验收通过
现象：武将觉醒武将被动后 点击重生下将在升级回去 觉醒技能不生效
预期：技能一但觉醒 只要武将达到技能开启的等级 就永远生效 且加成到武将面板
截图：

问题59：
状态：已修复 验收通过
现象：技能伤害面板显示不对 如下面截图
1.原空白面板鱼灵洗出一个5.8的技能伤害 面板显示10.2
2.俱乐部科技两个地方技能伤害加成是40 面板显示44
预期：鱼灵淬炼的技能伤害是多少面板就是多少 俱乐部科技加成是多少就是多少
根因：
1.客户端鱼珠面板按 PearlAttrConf.maxValue 展示技能伤害，attrId=9 的技能伤害为 attrNum0.2%，服务端属性计算误用 0.35% 系数，导致 29 点词条应为 5.8% 却计算成 10.15%，面板四舍五入为 10.2%。
2.俱乐部科技的技能伤害等特殊百分比在服务端 calculateLegionResearchBonuses 中按倍数累乘，两个 20% 被算成 1.21.2-1=44%，而客户端/策划预期是特殊属性直接相加为 40%。
修复：
1.服务端统一鱼珠属性系数，技能伤害 attrId=9 改为 0.2/100，主 role_getroleinfo 和 rankx 角色信息路径同步修复。
2.俱乐部科技基础属性（生命/攻击/防御/速度）继续累乘，技能伤害/暴击/格挡/爆伤/破甲等特殊属性改为百分比加法累计。
验证：
1.GOCACHE=/tmp/xianyu-go-build-cache go test . -run 'Test(PearlAttrBonusValue_SkillDamageMatchesClientDisplayScale|ApplyLegionResearchBonus_SpecialAttrsAreAdditive|CalculateHeroAttributes_IntegratesPearlAndLegionSkillDamageAdditively|Yuzhu_MissingPearlDataDoesNotPanic)' -count=1
2.GOCACHE=/tmp/xianyu-go-build-cache go test ./internal/gameplay/rankx -count=1
3.GOCACHE=/tmp/xianyu-go-build-cache go test . -run 'Test(SumAttrNumByID_UsesCurrentQuenchSide|Yuzhu_MissingPearlDataDoesNotPanic|PearlAttrBonusValue_SkillDamageMatchesClientDisplayScale|ApplyLegionResearchBonus_SpecialAttrsAreAdditive|CalculateHeroAttributes_IntegratesPearlAndLegionSkillDamageAdditively)' -count=1

问题60：
状态：验收通过
现象：鱼灵淬炼词条爆伤不生效 不加到面板上
预期：正常生效 且显示在面板上
截图：

问题61：
状态：验收通过
现象：鱼灵淬炼词条技能减伤属性显示在面板不正确
预期：词条加成是多少面板就是多少
截图：

问题62：
状态：已修复 验收通过
现象：俱乐部赛车内刷新赛车 有时候会刷新几十几百次不会变化 4次后必得神话 刷新后次数不会变动
预期：不会存在一直刷新赛车品质不变化的情况 刷新后几次必得神话会更具刷新次数变动
根因/处理：已查看问题描述、刷新按钮截图、客户端 cargoRaidModule.refreshSelfCar / CargoRaidParkingCarDialog、服务端 car_refresh -> domains/legion/cargoraid.Runtime.Refresh、角色缓存保存链路和 2026-05-20 账号 123456 服务端日志。验收账号主角色为 roleId=215046；cargoraid.log 显示多次刷新同一辆车时每次请求的 before 都回到默认颜色/refreshCount=0，回包 afterRefreshCount 永远从 1 重新开始，说明刷新逻辑已执行但角色状态没有留在缓存里。根因是 car_refresh 通过 SafeUpdateRole 保存整个角色时，RoleStore.Replace -> DeepCopyRoleManual 没有复制 Role.CargoRaid，导致刚刷出的赛车状态在写入角色缓存时被深拷贝丢弃，后续请求继续读取旧状态。已在角色手动深拷贝中补齐 CargoRaid 深拷贝；原先的刷新保底逻辑继续保留，普通车第 6 次及以后强制神话，大车特权/道具/付费车第 6 次及以后强制金车，并避免刷新后仍等于当前品质。
验证：已补 TestRoleStore_ReplacePreservesCargoRaidState 覆盖 Replace 不再丢失 CargoRaid.carDataMap；已补单测和集成路径覆盖普通刷新保底神话、大车特权保底金车、道具/付费车特权保底、保底后权重保持，以及基础 RuntimeSendRefreshClaim 流程；已跑 GOCACHE=/tmp/xianyu-go-build-cache go test ./internal/rolecachex -run 'TestRoleStore_(ReplacePreservesCargoRaidState|GetFieldsReturnsLatestEnchantMapAfterReplace|GetReturnsDeepCopy)' -count=1、GOCACHE=/tmp/xianyu-go-build-cache go test ./domains/legion/cargoraid -count=1。
截图：

问题63：
状态：已修复 待验证
现象：俱乐部赛车内 掠夺赛车 和他人战斗 双方伤害数据不对 赢了判输 跳过战斗必输
预期：伤害正常 赢就是赢 跳过战斗更具双方战力等来判断输赢
根因/处理：已查看问题描述、4 张掠夺战斗截图、客户端 cargoRaidModule.raidCar/createBattleInputData/battleEnd、服务端 car_raid / Runtime.Raid / 当前 CargoRaid 日志和 client_track 战斗失败日志。截图右上角 289911/dev28 不是账号，当前日志未找到该账号；日志中可见真实 CargoRaid 状态请求和历史 c_battleFail。客户端跳过/结算完全依赖服务端 battleData.result.isWin，不是客户端自行判定。服务端根因是掠夺战斗曾容易走本地 Go 引擎/错误目标快照，目标车队缺失时用攻击方本队弱化数据兜底，导致伤害统计、战斗展示和服务端最终 isWin 不一致，表现为看起来赢了但按输结算、跳过直接按错误结果输。已改为 car_raid 优先调用战斗服务并用其 isWin/statistic/battleVersion 结算，失败才回退本地 Go 引擎；目标队伍优先取被掠夺车辆保存的真实 battleTeam，缺失时再按目标角色构建，避免用攻击方本队当防守方。
验证：已补 TestRunCargoRaidBattle_UsesBattleServiceResult 单测和 CargoRaid 运行时/详情集成路径测试，覆盖服务端战斗结果、battleVersion、统计保留、掠夺积分与目标/护送元数据；已跑 GOCACHE=/tmp/xianyu-go-build-cache go test . -run 'TestRunCargoRaidBattle' -count=1、GOCACHE=/tmp/xianyu-go-build-cache go test ./domains/legion/cargoraid -run 'TestDetailFromRecommend|TestRuntimeRaidAddsGroupScoreOnSuccess' -count=1。
截图：

问题64：
状态：已修复 验收不通过
现象：咸王梦境内 挑战获取的属性加成道具不到账
预期：正常到账并且加成生效
根因/处理：已查看问题描述、两张梦境星级挑战截图、客户端 NightmareStarPanel/NightmareExtendData/NightmareStarWheelDialog、服务端 nmext_startboss/nmext_claimstarreward 与 domains/pve/nightmare/star.go、以及当前 2026-05-18/19/20 服务端日志。截图右上角 289911/dev28 不是账号，当前日志未检索到该账号；日志中可见真实 nmext_getinfo 账号但缺少本次 nmext_startboss 现场，已保留 nmext_startboss 的 hasKeyCntMap 诊断日志用于线上复核。根因是客户端战斗胜利页展示的是 NightMareStarBookConf.itemBonus 中的 type=57 星级道具，数量读取 roleNMExt.hasKeyCntMap；服务端原逻辑只在手动 nmext_claimstarreward 时把达成星级奖励写入 HasKeyCntMap，nmext_startboss 新增星数后只保存星星和次数，不发放本次刚跨档的道具，所以战斗后看到奖励但数量不变。已改为开打胜利结算时按新增总星数自动发放刚达成的星级奖励、写入 HasKeyCntMap、标记 StarRewardsClaimedMap，并回包 reward，避免后续手动领取重复发放。
验证：已补 TestHandleStarStartBoss_GrantsReachedBookRewardOnNewStars 单测/集成路径测试，覆盖战斗胜利新增 2 星后 36997 入账且奖励标记已领取；go test ./domains/pve/nightmare -count=1 和 go test . -run '^$' -count=1 通过。
截图：

问题65：
状态：已修复 待验证
现象：咸王梦境内盐瓶 麻辣蘸料等道具使用后无效
预期：使用后正常生效
根因/处理：已查看问题描述、两张道具使用截图、客户端 NightmareBattlePanel/NightmareBattleData、服务端 nightmare_restore 与梦境房间运行时源码、以及当前 2026-05-18/19/20 服务端日志。客户端在战斗成员菜单点击恢复后调用 NightMareService.restore({roomId, roleId})，成功后只依赖服务端房间状态刷新；服务端 nightmare_restore 之前固定返回 {code:0,msg:ok}，没有修改目标成员 fightRoleBase[*].battleData.team[*].curHp、没有递增恢复次数、没有推送 nightmare_roominfo_notify，因此客户端提示成功但血量与次数不变，看起来盐瓶/蘸料使用无效。已实现服务端恢复逻辑：校验调用者和目标都在同一梦境房间，恢复目标成员所有受损武将 curHp 到 hp，递增 restoreCnt，回包并广播最新 roomInfo；无血量变化时仍返回当前状态便于客户端刷新。
验证：已补 TestRestoreRoomMemberHP_RestoresTargetAndIncrementsCount 单测/集成路径测试，覆盖只恢复目标成员、非目标成员不变、restoreCnt 进入 roomInfo；go test ./domains/pve/nightmare -count=1 和 go test . -run '^$' -count=1 通过。
截图：

问题66：
状态：已修复 验收通过
现象：四圣满阶后 有的存在词条不满的情况
预期：四圣满阶时 上面三个属性词条应该都是满100状态
截图：

问题67：
状态：已修复 验收通过
现象：鱼灵淬炼时会可以同时装配两个同属性词条
预期：一个属性的词条只能装配一个 不能重复装配
截图：

现场追加：2026-05-17 01:14 武将升星保存失败
状态：已修复 验收通过
现象：账号 111111 / roleId 437026，hero_heroupgradestar 升英雄 118，trace_id 437026-111111-588-hero_heroupgradestar 返回 {"code":8,"msg":"保存失败"}。
根因/处理：已查看用户提供的协议日志、当前 protocol.log / gm_server.log / security.log、客户端 HeroTrainDialog._onUpgradeStar / HeroModule.sendHeroUpgradeStar、协议定义 HeroService.heroUpgradeStar、服务端 hero_heroupgradestar / herox.HeroHeroUpgradeStarFieldized / rolecachex.RoleStore 源码。日志显示英雄 118 从 1 星连续升到 20 星成功，最后成功回包为 star=20、items.118.quantity=399；之后 20->21 星失败。20->21 会额外写觉醒皮肤奖励 heroes.118.skin.<skinId>，但 rolecachex 字段化快速写入只支持英雄简单字段和装备槽位，未支持 heroes.<heroId>.skin.<skinId>，导致该跳转进入慢速重建路径并在现场返回保存失败。已补齐英雄皮肤条目的字段化快速写入；同时将扣碎片时 ErrInsufficientItemQuantity 映射为 code=7 材料不足，以后即使库存只剩 399 且需要 400，也不会再显示成保存失败。该修复不改变升星消耗配置，不自动补碎片，不绕过负数库存校验。
验证：已跑 GOCACHE=/tmp/xianyu-go-build-cache go test ./internal/rolecachex ./internal/gameplay/herox。

现场追加：2026-05-17 01:22 玩具激活失败
状态：已修复 验收通过
现象：账号 111111 / roleId 437026，lordweapon_unlock 激活 weaponId=1，trace_id 437026-111111-598-lordweapon_unlock 返回 {}；同一账号 01:20:38 至 01:22:38 连续 5 次 lordweapon_unlock 都返回 {}，未看到成功增量。01:30:39 后续 trace_id 437026-111111-599-lordweapon_unlock 成功返回 role.lordWeapon.1 和 items.1026.quantity=199500，Mongo 只读核对当前 lordWeapon.1.createTime=2026-05-17 01:30:39 +08:00，说明 01:22 现场未成功落库，后续才激活成功。
根因/处理：已查看问题17描述和截图、当前 protocol.log / gm_server.log / app.log / security.log、客户端 WeaponEquipConfirmDialog._onClickBuy / WeaponModule.sendBuyWeapon、客户端/服务端 WeaponConf.1.unlockCost、服务端 lordweapon_unlock 处理链 compat_fieldized_bridge -> lordweaponUnlockFieldized -> lordweaponx.LordweaponUnlockFieldized。服务端解锁逻辑在参数/配置异常、读角色失败、材料不足、已解锁、保存失败等分支全部 return nil，协议层最终序列化成 {}；客户端只判断 response.code，空对象会被当成成功，但没有 role/roleInfo 增量可合并，导致表现为“点击激活失败/状态没变化”，同时日志也无法看出真实失败原因。已将解锁失败分支改为明确 code/msg 并补低频原因日志；已解锁重试改为幂等成功且不扣材料；成功回包补 code=0 和 roleInfo。扣费仍严格使用原配置一致的 items.1026.quantity -500，并保留缓存侧负数库存校验，避免少扣、超扣或负数。
验证：已跑 GOCACHE=/tmp/xianyu-go-build-cache go test ./internal/gameplay/lordweaponx，并跑 git diff --check -- server/internal/gameplay/lordweaponx/fieldized.go server/internal/gameplay/lordweaponx/fieldized_test.go。

现场追加：2026-05-17 01:35 武将上阵失败 / RoleStore flush 失败
状态：已修复（待复测确认，需发布/重启清理运行中已污染内存）
现象：账号 111111 / roleId 437026，hero_gointobattle 上阵 heroId=121 到 slot=2，trace_id 437026-111111-57/58/59-hero_gointobattle 连续返回 {}；同窗口 RoleStore 报 flush_error phase=build_update ... err=Key task:complete:22 of inlined map conflicts with a struct field name。对照日志，01:35:14 hero_gointobattle 上阵 heroId=117 曾成功，回包含 statistics.task:complete:22=33065727；之后 01:35:50 开始 flush 报相同冲突，后续上阵全部 {}。
根因/处理：已查看当前 protocol.log / gm_server.log / app.log / security.log、客户端 BattlePrepareDeployPanel / HeroModule 对 ROLE.battleTeam 和 SyncBattleTeam 的使用、协议定义 Hero_GoIntoBattle、服务端 hero_gointobattle -> herox.HeroGoIntoBattleFieldized -> rolecachex.RoleStore。根因不是玩具解锁扣费逻辑，而是此前为支持动态 statistics.* 快速缓存写入时，把未知统计 key 统一写入 models.Statistics.Extra（bson:",inline"）；但 task:complete:22 已经是 models.Statistics.TaskComplete22 的结构字段。上阵成功写入 statistics.task:complete:22 后，该 key 落进 inline Extra，与结构字段 BSON tag 重名，导致后续 bson.Marshal(role) 构建全量更新或字段读取时失败，RoleStore 读写链路被卡，协议层返回 {}。已根治为：所有已有 Statistics / StatisticsTime BSON tag 的整数字段统一通过反射 tag 映射写入结构字段，不再进入 Extra；读取同样先读结构字段；若运行内存中已经污染到 Extra，持久化/读取前会迁回结构字段并删除 Extra 冲突 key。动态且未声明的统计 key 仍保留在 Extra，不影响兼容性。
验证：已补 server/internal/rolecachex/store_test.go 覆盖 statistics.task:complete:22、statistics.task:complete:5 不进入 Extra、历史污染 Extra 可被迁回结构字段且 roleToMap 不再冲突；已跑 GOCACHE=/tmp/xianyu-go-build-cache go test ./internal/rolecachex ./internal/gameplay/herox、GOCACHE=/tmp/xianyu-go-build-cache go test ./internal/gameplay/lordweaponx，并跑 git diff --check -- server/internal/rolecachex/store.go server/internal/rolecachex/store_test.go。