bug反馈 6.27 ¶

问题1：
状态：已修复 待测试服验证
待怪异塔开启验证
现象：怪异塔内11塔开始 没过10关后开箱子没有奖励 没有金钥匙
预期：没10关后获取的箱子正常开出奖励
根因：怪异塔服务端领奖进度按楼层保存为 10/20/30，但 EvoTowerReward 配置和客户端显示使用的是宝箱序号 1/2/3。服务端 evotower_claimreward 误用楼层值去查奖励配置，导致对应 10 关宝箱奖励没有按配置发放。
修复：服务端 evotower_claimreward 保留楼层进度作为领取门槛和持久化值，但按 rewardTowerId / RewardStep 转成宝箱序号读取 EvoTowerReward；同时返回给客户端的 rewardTowerId 按配置步长转成客户端需要的宝箱序号。
验证：已通过 go test ./domains/activity/evotower -run 'TestHandleClaimReward|TestLoadAndEnsure|TestHandleGetInfo' -count=1；go test ./entry/activity/activityentry -run 'TestEvoTower|TestRegisterEvoTower' -count=1。
截图：

问题2：
正式服账号:facaizzz 密码facai1226 时间：6.23 23:54-23：56
状态：已修复 验收通过
现象：鱼灵背包只有三颗星 图鉴使用连点器快速点击可以多升一星
预期：实际鱼灵有几星 图鉴就点亮几星 不可以和实际鱼灵不一致
根因：book_upgradeartifact 只按鱼灵图鉴配置最大星级判断，没有按角色当前实际拥有的最高鱼灵星级做上限；collection_getinfo/鱼灵升星后的同步只同步展示用 artifactId，不会把已多升的 claimedStar 压回真实拥有星级。连点器只是高频触发了这个服务端校验缺口。
修复：服务端统一按背包、武将已装备鱼灵、珍珠鱼灵槽位扫描实际拥有最高星级；图鉴升级时 nextStar 不能超过实际拥有星级；同步/修复入口会把已有异常 claimedStar 压回实际拥有星级，并扣回对应鱼灵图鉴积分；book_upgradeartifact 保存失败不再静默忽略。
验证：已通过 go test ./domains/growth/book -run 'TestUpgradeArtifactBook|TestPruneInvalidArtifactBooks|TestSyncArtifactBooks' -count=1；go test ./internal/artifactutil -count=1；go test ./entry/growth/bookentry -run 'TestHandleUpgradeArtifact|TestHandleUpgrade' -count=1；go test ./internal/artifactx -run 'TestHandleUpgradeStarBagSyncsArtifactBookIDButKeepsManualClaimedStar|TestHandleUpgradeStarBagPushesArtifactBooksWhenBookIDUnchanged|TestHandleLotteryPrunesNonArtifactBookFromInventoryItem' -count=1；git diff --check。
截图：

问题3：
测试服账号rty520520 密码520520 时间：6.24 15:44
状态：已修复 验收通过
现象：俱乐部科技升级或者取消 加成不会立马显示在面板上 需要退出游戏在进入才会显示当前正常加成
预期：俱乐部科技升级或者取消 无损转换加成会立马显示在武将面板 实时刷新
根因：俱乐部科技升级、重置、无损转换后，服务端只下发 legionResearch、power 等简化数据，没有下发重新计算后的 role.heroes；武将面板读取客户端本地 ROLE.heroes，所以当前界面不会实时刷新，退出重进获取完整角色数据后才正常。
修复：legion_research、legion_resetresearch、legion_exchangeresearch 返回中补充战斗队伍武将的最新面板属性增量，并复用本次计算出的战力，避免额外重复重算。
验证：已通过 go test ./domains/legion/tech -count=1；go test . -run 'TestHandleUpgrade|TestHandleReset|TestHandleExchange|TestLegionResearch|TestBaseLegionResearch|TestApplyLegionResearchBonus' -count=1；git diff --check。
截图：

问题4：
状态：已修复，待测试服复验
备注：升级后奖励领取过后还是显示未领取的 UI，新问题已修复。
截图：
现象：限时活动日活动内彩玉狂欢活动 彩玉灵脉无法升级 点击升级无反应
预期：可以正常使用对应彩玉精髓升级灵脉
根因：客户端发送 activity_upgradequenchcarnivallevel / activity_claimquenchcarnivallevel，服务端缺少对应路由和处理器，点击后无有效升级响应。
修复：补齐彩玉灵脉一键升级和领取等级奖励协议；升级按当前材料升到可负担最高等级并同步 qc:l/材料数量，领取按本周 qc:c 幂等发放未领等级奖励；同一角色加锁防止双击/并发重复扣发。二次修复领取后 UI 仍显示未领取：升级/领取回包同时返回 role 与 roleInfo 镜像，确保客户端本地 ROLE.statistics.qc:c 能被同步刷新为已领取等级。
验证：go test ./domains/activity/quenchcarnival -count=1、go test ./entry/account/wsentry -run TestRegisterActivityAndSystemHandlers_WiresExpectedCommands -count=1 通过。
截图：

问题5：
正式服账号：facaizzz 密码：facai1226
状态：已修复，待正式服验证
现象：每次使用无损换将都会特别卡 出现转圈圈情况
预期：使用无损换将不会卡顿
根因：生产一区 Docker JSON 日志显示 hero_exchange 单次回包可达 600KB-960KB，账号 facaizzz/100316514 最大 respWireBytes=960945、handlerMs=753.68、e2eMs=773.36。服务端 finalizeHeroExchangeResponse 为了兜底刷新旧状态，把 collectAllHeroIDs(role) 合入回包，并且底层 GetOptimizedRole 已可能把 role.heroes 变成全量，导致每次无损换将都下发 63 个武将；客户端合并/渲染大 ROLE.heroes 时卡顿。
修复：服务端 hero_exchange 只保留本次交换的两个武将和当前阵容武将的完整 payload，并主动裁剪底层 diff 已经带出的无关背包武将；单个相关武将字段不裁剪，继续保留装备、淬炼、属性、技能、战力、鱼灵 artifactId、珍珠 pearlId、HB 等。power、battleTeam、privilege、enchantMap 等刷新字段保持原样，避免影响战力、赐福、鱼灵、珍珠等刷新链路。
验证：先按 TDD 增加红灯回归，旧逻辑会把无关武将 103 注入/保留到回包；修复后通过 env GOCACHE=/tmp/xianyu-go-build GOTMPDIR=/tmp go test ./internal/gameplay/herox -count=1，覆盖无损换将、战力保存污染、鱼灵/珍珠交换、淬炼清理、阵容位、赐福 UID 映射；另通过 env GOCACHE=/tmp/xianyu-go-build GOTMPDIR=/tmp go test . -run '^$' -count=0 和 git diff --check。正式服发布后需复查 cmd=hero_exchange 的 respWireBytes 从 900KB 级下降，日志 rawRoleHeroes=false，并用玩家账号确认无损换将后战力/阵容/装备淬炼/赐福/鱼灵/珍珠即时刷新。
截图：

问题6：
状态：已修复 验收通过
现象：珍宝阁内典韦四圣飞艇无法正常佩戴 点击佩戴无反应
预期：可以正常佩戴典韦四圣飞艇
根因：客户端装配典韦飞艇会发 role_loaddress，dressType=3；服务端装配前会校验外观 ID 是否在可装配飞艇集合里，但典韦四圣飞艇 2117 和星魂飞艇 21172 漏在服务端默认飞艇集合外，导致服务端返回“外观ID无效”。客户端该页面没有明显错误提示，所以表现为点击无反应。
修复：补齐服务端飞艇外观集合中的 2117、21172，并补充 rolecosmetics 白名单单测和 role_loaddress 根包回归用例。
验证：已通过 go test ./internal/rolecosmetics -count=1；go test . -run TestRoleLoadDressFieldized_AcceptsDianweiCollectionDressIDs -count=1；git diff --check。
截图：

问题7：
状态：已修复 待测试服验证
待怪异塔开启验证
现象：怪异塔内 俱乐部目标未开启 处于锁定状态
预期：俱乐部目标正常开启
根因：客户端俱乐部目标入口读取 SERVER_DATA.evoTower.bindLegionId 判断当前俱乐部是否已绑定；服务端 ensureState 只从历史 activityRecord.evoTower 读取 bindLegionId，已有俱乐部的玩家若旧记录为 0，evotower_getinfo 仍返回 0，导致客户端一直显示锁定。
修复：服务端加载怪异塔状态时，如果 bindLegionId 为空且角色当前已加入俱乐部，则回填当前 role.LegionId 并保存；怪异塔俱乐部特权相关接口也透传同一份 EvoTower 配置，保证返回的 evoTower payload 与其他接口一致。
验证：已通过 go test ./domains/activity/evotower -run 'TestHandleClaimReward|TestLoadAndEnsure|TestHandleGetInfo' -count=1；go test ./entry/activity/activityentry -run 'TestEvoTower|TestRegisterEvoTower' -count=1。
截图：

问题8：
状态：已修复 验收通过
再次复测玩具：测试服账号：rty520520 密码520520 ID：100216517 时间 6.28号 0:06
再次复测俱乐部科技时间： 6.28号 0:07 (刚好和不佩戴宠物玩具的属性一样 大概率是宠物和玩具的属性未加成上面板)

备注：测试服账号：rty520520 密码520520 ID：100216517 时间：6.27 15:12
现象：每次玩具下掉再佩戴 面板攻击血量显示和原来不一致 重新进入游戏后恢复正常 （俱乐部科技切换后也是如此）
预期：下掉再重新佩戴玩具 面板攻击血量应和原本完全一致
根因：玩具上下阵/俱乐部科技切换后的在线属性重算走 LoadRoleViewForBonus 轻量 Role 视图，该视图漏读 collectionClaimScore 和 roleLegacy。完整登录会加载这两个字段，所以重进后面板恢复；在线切换时返回的 role.heroes 少算珍宝阁阶段固定攻血和功法/传承固定攻血，表现为攻击、血量、战力低于原来，速度等不依赖这两个字段的属性能正常恢复。
修复：轻量属性视图补齐 collectionClaimScore、roleLegacy，玩具切换、俱乐部科技切换、装备/武将等共用在线重算路径都会带上与登录全量公式一致的固定攻血依赖；未改倍率公式，避免数值放大。
验证：已新增回归 TestLoadRoleViewForBonusWithBattleTeam_LoadsFlatAttackHpBonusFields，并通过 go test ./internal/bonusviewx -count=1、go test ./internal/gameplay/lordweaponx -run 'TestLordweapon|TestLordWeapon|TestChangeDefault|TestUpgradePassive|TestExchange' -count=1、go test . -run 'TestBuildHeroesDataFromBonus_IncludesCalculatedAttribute|TestSafeLordWeaponPassiveSkill|TestCalculateTotalSkillAttributes|TestCalculatedBonusCoversAllRoleHeroes|TestLordWeapon' -count=1。本地 6.27 15:12 服务端协议日志未检索到该角色记录，待测试服用同账号复测上下玩具前后攻击/血量是否完全回到原值。
截图：

问题9：
账号facaizzz 密码zzz1226 ID：100316514 时间6.27 15:50
状态：已修复 待正式服验证
现象：十殿开启后直接进入十殿9 有的玩家是直接进入别的关卡（是否因为记录玩家历史挑战最高关卡开始）
预期：每次十殿开启必须从十殿第一关开始
根因：服务端创建十殿新房间且房间无进度时，会读取队员本周历史 NightmareWeek.MaxLevel，按 maxLevel + 1 初始化 CurMonsterCfgId。角色 100316514 在 6.27 15:25 已有 maxLevel=8，15:50 新房因此直接初始化到 bossCfgId=12（十殿9），不是客户端显示错。
修复：十殿新开/无进度房间固定从 nightmareFirstBossCfgId() 初始化；已有进行中房间仍由 nightmareRoomHasProgress 保护，不重置当前战斗进度。
验证：已通过 env GOCACHE=/tmp/xianyu-go-build GOTMPDIR=/tmp go test . -run TestNightmareEnsureRoomForTeam_StartsAtFirstLevelForNewRun -count=1。
截图：

问题10
账号facaizzz 密码zzz1226 ID：100316514 时间6.27 16:00
状态：已修复 待正式服验证
现象；通过十殿9后 奖励显示已领取 未到账
预期：奖励需玩家手动点击领取 且正常到账
根因：服务端 buildNightmareOnceRewardForRole 把 bossType <= NightmareWeek.MaxLevel 的阶段奖励全部推导成 onceReward=true，导致“已通关”被客户端展示成“已领取”；同时隐藏阶段 bossId=11 通关时只写 nightmareWeek.killAward.11=1，没有发 killReward，形成已领取但未到账。
修复：onceReward 只由真实已领取/已发放的 killAward>0 生成，不再从 MaxLevel 推导；隐藏阶段通关时在同一次角色字段 patch 中发放 killReward 并标记 killAward，同角色加锁和已领取检查避免并发重复发。
验证：已通过 env GOCACHE=/tmp/xianyu-go-build GOTMPDIR=/tmp go test . -run 'TestBuildNightmareOnceRewardForRole_DoesNotInferClaimedFromMaxLevel|TestPersistNightmareHiddenBossProgress_GrantsRewardBeforeMarkingClaimed' -count=1。
截图:

问题11：
账号facaizzz 密码zzz1226 ID：100316514 时间6.27 16:00
状态：已修复 验收不通过
现象：十殿每周通过关卡后 面具奖励每周都可以领取一次 领取后奖励不到账
预期：面具奖励一个人终身只可以领取一次 奖励正常到账
根因：面具/魅力礼包服务端 ClaimCharmGift 和 ClaimAllCharmGifts 使用 sameCharmWeek(charmGift, now) 做领取限制，跨周后会再次进入领取逻辑；但对应特权已存在时 grantCharmPrivilege 没有新增 delta，所以玩家感知为每周可领、点击成功但没有新到账。
修复：面具/魅力礼包改为生命周期一次领取，只要 charmGift 有领取时间或 charmData 已有该 charmId，就直接返回已领取，不再增加数量、不保存无效变更；首次领取仍正常写 charmData/charmGift 并同步特权。
验证：已通过 env GOCACHE=/tmp/xianyu-go-build GOTMPDIR=/tmp go test ./domains/pve/nightmare -run 'TestHandleClaimCharm(RejectsLifetimeClaimedGift|ClaimAllRejectsLifetimeClaimedGift|ClaimAllSkipsAlreadyClaimedWeek|PersistsAndReturnsClientFields|ClaimAllPersistsUnclaimedGifts)' -count=1。
截图：

问题12：
账号facaizzz 密码zzz1226 ID：100316514 时间6.27 16:05
状态：已修复 验收不通过
现象：十殿转盘抽奖后本周已获得奖励显示为空
预期：正常显示本周抽奖转盘获得的奖励
根因：服务端 clickNightmareTurntable 只扣 turntableLeftCnt 并发放道具，没有写入 nightmareWeek.turntableReward；buildNightmareWeekAwardForRole 返回空 map，客户端“本周已获得奖励”自然为空。玩家 100316514 数据也验证为 turntableLeftCnt=0、turntableReward={}。
修复：抽奖成功后按转盘配置 id 轻量记录抽中次数 nightmareWeek.turntableReward.<confId> += 1；返回/重登读取时按 CompassReward 配置还原成客户端期望的奖励数组，重复抽中同一格会展开为多条展示记录，周重置仍清空。
验证：已通过 env GOCACHE=/tmp/xianyu-go-build GOTMPDIR=/tmp go test . -run TestClickNightmareTurntable_AppliesRewardAndReturnsRoleDelta -count=1。
截图：

问题13：
正式服：账号facaizzz 密码zzz1226 ID：100316514 时间6.27 16:22
状态：未处理
现象：星级挑战内 攻打第一关 秦广王boss赢了判定输
预期：赢就是赢 所有boss都不会赢了判定输
截图：

问题14:
状态：已修复
预期：游戏内私信设置门槛 充值大于10元后 才可以发送私信
截图：

根因：客户端好友详情“发送私信”按钮走 SystemService.sendMail({roleId, content})，实际协议是 system_sendmail；服务端 MailSendHandler 只校验发件人、收件人、内容和附件伪造，没有读取发件人真实充值金额，因此未充值或真实充值不超过 10 元的角色也能发送并写入日常邮件。
修复：system_sendmail 构造私信发件人时读取 charge_orders 真实充值缓存口径 getPaidRechargeCentByRoleIdCached，并在私信归一化阶段要求真实充值金额必须大于 1000 分；不足时返回 code=1,msg=发送私信需要真实充值大于10元，不会落库。超过 10 元的玩家仍按原逻辑发送无附件日常私信。
验证：GOCACHE=/tmp/go-build GOTMPDIR=/tmp go test ./entry/mail/wsentry -count=1；GOCACHE=/tmp/go-build GOTMPDIR=/tmp go test . -run 'TestMailSendHandler|TestRegisterAccountAndMailHandlers|TestRootEntryInterfaces|TestMail' -count=1。已检查 2026-06-27 本地 client_track/server 日志，没有可关联的 system_sendmail 现场 trace，本问题按截图、客户端入口和服务端确定性校验缺口闭环。

问题15：
状态：已修复，待测试服验证
预期：更改三卡对应奖励对应奖励ui
终身卡奖励更改为：
红将万能碎片100
白玉1万
彩玉40
灵贝20
蓝玉50
成长脆饼100
精铁5000
进阶石2000
截图：
月卡奖励更改为：
金砖4000
彩玉20
灵贝20
蓝玉100
成长脆饼100
截图：
周卡奖励更改为：
彩玉20
白玉4000
扳手2000
蓝玉*50
截图：
根因：客户端福利活动三卡 UI 读取 CardConf.cardRewardDaily，服务端每日领取读取独立 card_rewards.json/DB 后台配置，原配置仍是旧奖励。
修复：同步调整 4001 周卡、4002 月卡、4003 终身卡在服务端 CardConf、客户端 CardConf 和服务端 card_rewards.json 的每日展示/发奖配置，避免 UI 和到账不一致。
验证：jq empty server/config/config.json server/config/config1.json client/assets/config/config.json server/config/card_rewards.json；GOCACHE=/tmp/go-build GOTMPDIR=/tmp go test ./internal/planconfig -run TestCardDailyRewardConfigMirrorsPlanningItem15 -count=1。部署后若线上启用 DB 后台配置，需迁移/重载 card_rewards_config。

问题15：
状态：已修复，验收通过
现象：功法内功法探索 探索所得奖励显示和实际领取残卷数量不一致
预期：显示多少领取就是多少
截图:

根因：客户端探索展示按 produceTimeMax + LegacyChargeReward.collectTimeAdd 计算上限，服务端 legacy_claimhangup 只按基础 produceTimeMax 结算。截图等级 2 配置可复现：6 小时基础上限产出 96，特权增加 18 小时后展示为 384。
修复：服务端领取上限叠加当前赛季已达成的功法特权 collectTimeAdd，未达上限时仍按真实探索时长结算。
验证：GOCACHE=/tmp/go-build GOTMPDIR=/tmp go test . -run 'TestLegacyClaimHangUp_(UsesBaseMaxWithoutPrivilege|AddsPrivilegeCollectTimeToMax|PrivilegeDoesNotOverProduceBeforeElapsedCap)' -count=1。

问题16：
正式服：账号facaizzz 密码zzz1226 ID：100316514 时间6.27 20:47
状态：已修复，验收通过
现象：对战房间内 开始战斗后 只有房主看到的页面正常 其他人看到的页面不正常 且可以跳过战斗
预期：所有人看到的对战页面正常 无法跳过战斗
截图：

根因：客户端房间处于 wait/fight 时点击操作按钮会手造一个空 PKRoom_FightNotify 并以 valid=false 进入战斗，非房主未拿到真实 battleData 时会进入异常/可跳过界面。
修复：移除空 battleData fallback，点击时改为请求房间详情并走服务端 CurrentFightNotify 重放；拿不到真实战斗数据时只提示等待同步，不进入战斗 UI。
验证：静态检查确认 RoomFightPanel.js 不再存在空 PKRoom_FightNotify fallback；GOCACHE=/tmp/go-build GOTMPDIR=/tmp go test . -run 'TestPKRuntimeRoom_CurrentFightNotifyPayload_(ReplaysActiveBattleForWatcher|DeniesNonMemberWhenWatchDisabled|MirrorsActiveBattleForDefender)' -count=1。仍需双号测试服回归非房主开战 UI。

问题17：
状态：已修复，验收通过
预期：对战房间内 标准对战设置永久关闭 不开启
截图：
根因：标准房是 roomType=2 入口，不是普通配置开关；pkroom.open 会误伤高级房，原服务端也未强制拒绝标准房创建/加入/改规则/开战。
修复：客户端隐藏标准房入口；服务端对 roomType=2 在创建、加入历史房、改规则和开始战斗入口统一返回“标准对战已关闭”，高级房不受影响。
验证：GOCACHE=/tmp/go-build GOTMPDIR=/tmp go test . -run 'TestPKRoom(CreateHandler_RejectsClosedMatchRoomType|JoinHandler_RejectsExistingClosedMatchRoom|ChangeRuleHandler_RejectsClosedMatchRoom|StartBattleHandler_RejectsClosedMatchRoom)' -count=1。