bug反馈 6.8 ¶

问题1：
状态：已修复（待回归）
验收通过
现象：阵营光环进入游戏后加成不生效
预期：阵营光环达到每个等级的加成 进入战斗后正常加成到上阵的5个武将身上
截图：
根因：入战 leftTeam 构造只使用武将当前面板 Attack/Hp，没有读取 ConstantConf.auraStar/auraColor、AuraConf、HeroConf.club 来计算阵营光环，也没有把光环的攻击/生命百分比加成写入战斗用 attack/hp/curHp。
回归建议：配置满足 4 个同阵营武将的光环条件后进入任意普通战斗，抓 battleData.leftTeam.team，确认上阵 5 个武将的 attack、hp、curHp 都按对应 AuraConf 加成提升；再用不满足阵营数量或星级/品质限制的阵容验证不加成。

问题2：
状态：已修复（待回归）
验收通过
现象：俱乐部内申请列表里玩家战力显示不对
预期：正确显示玩家当时的阵容战力
截图：


根因：俱乐部申请列表直接返回申请入会时保存在俱乐部申请队列里的战力快照，申请后玩家战力变化时列表不会重新读取角色当前权威战力；兼容入口也没有给申请列表注入战力构建逻辑。
回归建议：用一个玩家申请加入俱乐部后再提升/刷新战力，管理员打开申请列表，确认列表战力与该玩家当前阵容战力一致；再分别执行同意、拒绝、重新打开申请列表，确认返回的 roleList 战力仍正确。

问题3：
状态：已修复 验收通过
现象：好友推荐里免费刷新刷不出人
预期：点击刷新可以正常刷新到玩家
截图：
根因：免费刷新接口 friend_refrecommend 查询的是旧集合 role，而真实玩家数据在 roles 集合，导致查不到真实玩家后落到推荐兜底数据。
回归建议：准备多个真实角色账号，打开好友推荐后点击免费刷新，确认返回真实玩家昵称/头像/战力，不再只显示“推荐玩家”兜底行；连续刷新多次确认接口稳定返回真实候选。

问题4：
状态：已修复（待回归）
验收通过
现象：游戏好友内 点击一键赠送和领取金币无效 无法正常领取和赠送 完不成每日任务里的赠送3个好友金币
预期：点击一键赠送和领取可以正常领取和赠送好友金币 送三个好友金币可以完成每日任务
截图：

根因：客户端有 friend_receive 领取请求但服务端未注册处理器；好友列表没有根据对方 friendPresented 计算 isReceive，也没有持久化 friendReceived；friend_batch 只做赠送不做领取，赠送也未累加 dailyTask.complete.3。
修复：注册 friend_receive 协议并新增单独领取逻辑；好友列表按双方 friendPresented/friendReceived 计算可领取状态；friend_batch 同时处理一键赠送和一键领取，领取增加 hallEnergy 并写入 friendReceived，赠送按实际新赠送人数累加 dailyTask.complete.3。
验证：已通过 go test -count=1 ./entry/social/friendentry、go test -count=1 ./domains/social/friend、go test -count=1 ./entry/account/wsentry -run TestRegisterSocialHandlers_WiresExpectedCommands、go test -count=1 . -run 'TestRegisterSocialHandlers|TestFriend|Test.*friend'。
回归建议：两个账号互为好友，A 给 B 赠送金币后，B 的好友列表应出现可领取状态；B 单独领取和一键领取都应增加 hallEnergy 并写入领取记录；A 一键赠送 3 个好友后，日常任务“赠送3个好友金币”进度应完成。

问题5：
状态：已修复（待回归）
验收通过
现象：功法内抽出的橙色品质以下的卡也带有特殊属性
预期：只有橙色级以上的卡才会带有特殊属性
截图：

根因：legacy_create 生成特殊属性时只按抽卡档位概率 buildLegacyExtAttrs(createLevelID) 判断，没有传入并校验实际抽出的功法品质 color，导致低品质也可能命中特殊属性。
回归建议：连续抽取低于橙色/高品质阈值的功法，确认 extAttrs/extAttrNums 为空，客户端不显示特殊属性；同时抽高品质功法确认原本应有的特殊属性概率仍正常。

问题6：
状态：验收通过
备注：有出现珍卡 没有附加属性的情况
现象：功法内抽出的珍卡会出现特殊属性不是双满的情况
预期：所有珍卡一定是双满3.0的属性
截图：
根因：珍卡仍走普通特殊属性概率和值域随机逻辑，没有按珍卡品质强制写入双特殊属性满值。
回归建议：抽到珍卡时检查服务端返回的功法条目，extAttrs 应固定为 604、605，extAttrNums 应固定为 300、300；客户端展示应为两个 3.0 特殊属性。

问题7：
状态：验收通过
现象:单周活动内累计招募达标一轮后 自选大奖无法正常领取 点击领取无反应
预期：可以正常领取奖励
截图：

根因：单周活动自选大奖客户端按活动 openTime/endTime 过滤 week:act:cr:cnt:<活动类型> 已领取次数，旧周领取次数不会计入本周可领次数；但服务端 activity_claimweekactreward 只读取 role.Statistics.WeekActClaimCnt*，没有校验 role.StatisticsTime.WeekActClaimCnt* 是否属于当前周，导致上周已领取次数残留时，本周完成第一轮后服务端误判“没有可领取的自选大奖”，客户端又只打印错误不弹提示，表现为点击领取无反应。
回归建议：用上周已领取过累计招募自选大奖的角色，本周完成累计招募第一轮后打开自选大奖，剩余领取次数应为 1，选择任意奖励并确认后应正常发放，week:act:cr:cnt:1 与 statisticsTime.week:act:cr:cnt:1 更新为本周；同账号重复点击应提示无可领次数，不应重复发奖。同步覆盖累计开箱、累计消耗金砖两个同入口活动类型。

问题8：
状态：已修复（待回归）
验收通过
备注：正式服账号：facaizzz 时间：6.8号 7:20
现象：更换皮肤会导致武将战力下降 （应是哪里加成掉了）
预期：更换皮肤不会导致武将战力下降
截图：



根因：hero_useskin 把“切换外观”当成战力变更操作，切换时会清缓存、重算并写入 power；但当前规则应按单个武将已拥有皮肤里的最大加成计算，获得皮肤时刷新战力，切换皮肤不应重新改战力。
回归建议：同一武将拥有多个皮肤时，记录切换前角色总战力和该武将战力，连续切换低加成/高加成/默认皮肤后战力应保持不变，仅 useSkin 变化；新获得一件更高加成皮肤时才刷新该武将和总战力；确认同一武将多个皮肤只取最大加成不重复叠加。

问题9：
状态：已修复 验收通过
现象：孙坚专属鱼龙鱼古锭属性破甲抵抗免控加成不生效 不显示在面板
预期：加成正常生效且显示在面板上
截图：


根因：龙鱼·古锭对应 ArtifactConf 12151-12155，客户端鱼灵弹窗展示的是 attrs 中的血量、破甲抵抗(52)、免控(63)以及 attrsLimit 中的孙坚专属血量；但武将属性面板依赖服务端用同一份配置通过 YubyidWithHero 写入 Hero.Attribute["52"]/["63"]。此前 server/client/runtime 配置链路未同步校验，导致说明里有 52/63 加成，服务端面板属性未稳定体现。
回归建议：给孙坚装备五星龙鱼·古锭后，属性面板破甲抵抗应增加 30%，免控应增加 20%，血量应同时体现基础 18% 和孙坚专属 18%；再换给非孙坚时只保留基础属性，不触发专属血量。同步检查 server/config/config.json、server/config/config1.json、client/assets/config/config.json、server/runtime/data/ArtifactConf_extracted.json 的 12151-12155 配置一致，并跑 SunJianExclusiveFishAttrsStayInSync 与 YubyidWithHero 相关回归。

问题10：
状态：验收通过
现象：俱乐部赛车奖励领取后奖励不到账
预期:领取的奖励成功到账
截图：

根因：俱乐部赛车收车入口 car_claim 调用 carRaidRuntime.Claim 后只把车辆状态重置、记录行程日志，并把 reward/points 返回给客户端弹“恭喜获得”；但没有把 reward 实际写入 role.Gold、role.Diamond 或 role.Items，响应里也没有返回对应 role 增量，导致看得到奖励弹窗但背包/货币不到账。
回归建议：发出一辆可收车的普通/高级赛车，领取后检查服务端角色数据和客户端背包/货币：道具类奖励数量增加，type=1 金币增加，type=2 金砖增加，type=3 道具增加；同时确认车辆被重置、行程记录仍存在、重复领取同一辆车不会再次发奖。

问题11：
状态：已修复（待回归）
验收通过
现象：宠物精炼词条有爆伤抵抗
预期：词条不包含爆伤抵抗
截图：

根因：宠物精炼概率配置 server/config/pet_prob.json 的 quenchAttrs 和 functional_percent 分组里包含 attrId=60，语言配置中该属性为“爆伤抵抗”；规则只允许“暴击抵抗”attrId=59，不允许“爆伤抵抗”attrId=60。
回归建议：大量刷新/精炼宠物词条，确认候选和确认后的词条池中不再出现“爆伤抵抗”；同时确认“暴击抵抗”等其它合法功能词条仍可正常出现。

问题12
状态：未处理
现象：咸将塔爬塔会出现赢了判定输
预期：任何副本 任何战斗都不会存在赢了判输
截图：

问题13：
状态：未处理
现象：深海灯神第二关 boss伤害不对 每次只能造成一点伤害 且赢了判定输 跳过必输
预期：boss伤害正常 不会出现赢了判定输
截图：

问题14：
状态：已修复（待回归）
验收通过
现象：竞技场内击败他人后显示减分 但是实际排行榜内积分没变化
预期：增减分排行榜上会跟着变化
截图：


根因：竞技场战斗 fight_startareaarena 胜利结算会把攻击方加分、真实防守方扣分写入 RoleStore 缓存，并异步落 Mongo；客户端战斗后立刻触发 arena_getarearank 刷榜。排行榜主体 rankx.AreaRankHandler 从 Mongo 查询榜单行，只把当前玩家这一行替换为缓存中的最新角色，所以截图里自己从 1792 变 1811，但被击败的对手仍显示 Mongo 旧分 1727。结算弹窗的 oppoScore=-19 是正确的，坏的是榜单刷新读到了未落库的对手旧行。
回归建议：用两个真实角色进入同一竞技场榜单，A 击败 B 后停留在线状态立即返回榜单，确认 A 分数增加、B 分数同步减少，且排行顺序按新分重新排序；同时重新打开竞技场/重登后分数保持一致。覆盖胜利扣对手分、失败给对手加分、对手分数接近 1000 下限三种场景。

问题15：
状态：已修复（待回归）
验收通过
现象：金币礼包开出的金币数量不对
预期：应该按照挂机时间内每小时产出金币*4计算
截图：


根因：客户端金币礼包说明来自 ItemConf[3001].params[1]=14400 秒，数量展示按 params[1] / ConstantConf.stayRewardTime * 当前 hangUp.stayId 对应 StayRewardConf.stayFixedReward[金币].value 计算，也就是当前挂机 4 小时金币。截图中 1000 关金币效率约 515.5 万/小时，对应配置值 7160，单个礼包应为 7160 * (14400 / 5) = 2062.08 万。服务端 item_openpack 对 3001 走了单独旧分支，使用 levelId * 1000 * 数量，完全绕过道具参数、挂机配置和当前 hangUp.stayId，所以 10000 关开出 1000 万。
修复：item_openpack 的 3001 分支改为优先读取当前角色 hangUp.stayId、config1.ItemConf[3001].params[1]、config1.ConstantConf.stayRewardTime 和 config_ap1.StayRewardConf 计算金币；配置或角色挂机数据异常时保留旧公式兜底，避免开包失败。返回奖励、金币增量和背包扣减字段保持原协议。
验证：已补充 TestBuildHangUpGoldPackRewardValue_UsesFourHourCurrentHangUpGold、TestBuildHangUpGoldPackRewardValue_UsesStayIDConfigRow，并通过 go test -count=1 . -run 'TestBuild(HangUpGoldPackRewardValue|ConfiguredOpenPackRewards|ConfiguredChoosePackRewards)'、go test -count=1 . -run 'Test.*(OpenPack|HangUp|Configured.*Pack|GoldPack)'。完整根包 go test -count=1 . 仍有既有非本问题失败（如 client_track 签名、PK 观战战力、PVE 默认 shape），本次相关路径已定向通过。2026-06-08 截图时间附近本地日志只搜到协程统计，未搜到 item_openpack 请求链；该问题为确定性配置/公式错误，已用截图、配置、代码路径和回归测试验证。
回归建议：用 1000 关角色开 1 个金币礼包，确认奖励约 2062.08 万且背包数量减少 1、角色金币增加同值；再批量开多个，确认按数量倍增。换一个低关卡角色开包，确认取当前 hangUp.stayId 对应配置行，不是 levelId * 1000 或配置表下标错位。

问题16：
状态：已修复（待回归）
现象：灯神挑战存在一个武将分化多个上阵
预期：一个武将只能存在一个
截图:
根因：客户端灯神布阵 GenieDeployDataAdapter 会用 hasSelectId/inTeamSet 限制同一 heroId 只能选一次，并通过 GenieModule.sendStartGenie -> FightService.startGenie 把 battleTeam/genieId/lordWeaponId/petUId 发到 fight_startgenie。但服务端灯神开战链路原来没有在入口统一归一阵容：saveGenieBattlePreset 和 buildGenieLeftTeam 各自会去重，selectGenieBattleRole -> GetMergedBattleTeamRole -> GetroleWithBonusForBattleTeamAndPet 却仍先拿原始 req.BattleTeam 做临时上阵角色/战力/属性合并。这样旧客户端状态、异常包或脏预设带入重复 heroId 时，同一武将会进入部分开战计算路径，表现为灯神挑战里一个武将分化到多个上阵槽位。
修复：internal/geniex.FightStart 和 buildGenieBattleDataWithResult 入口统一调用 normalizeGenieFightStartRequest，只保留 0-4 槽位内每个 heroId 的首次出现槽位，过滤 0/非法/重复槽；保存预设、临时加成合并、战斗左队和返回给客户端的 role.genieBattleTeam 都使用同一份清洗后的阵容。
验证：先补 TestFightStart_DedupesDuplicateBattleTeamBeforeMergeAndResponse，红测时失败在 GetMergedBattleTeamRole 收到 {"4":110} 重复槽，证明重复阵容会先进入临时合并入口；修复后通过 go test -count=1 ./internal/geniex -run TestFightStart_DedupesDuplicateBattleTeamBeforeMergeAndResponse、go test -count=1 ./internal/geniex、go test -count=1 . -run 'Test.*Genie|Test.*fight_startgenie|Test.*FightStartGenie'。2026-06-08 截图时间附近本地 server/logs/2026-06-08/app.log 和 client_track-2026-06-08.log 未搜到对应 fight_startgenie/genie 请求链，本问题按截图、客户端请求路径、服务端入口/合并/保存路径和回归测试验证。
回归建议：用同一账号打开灯神挑战布阵，选择 3-5 个武将进入挑战，确认同一武将无法在多个槽位同时出现；再用调试包或脏数据构造 battleTeam={"0":118,"2":110,"3":104,"4":110} 发起 fight_startgenie，确认战斗左队、战力计算、保存的 ROLE.genieBattleTeam[club] 和返回包里都只保留 0/2/3 三个槽，4 号重复槽被清掉。切换灯神国家、重登后再次进入，确认旧重复预设不会恢复。

问题17：
状态：验收不通过
现象：通行证奖励内没有皮肤
预期：每一期通行证一定有一个皮肤
截图：
根因：截图是 2026-06-08 的竞技之路通行证，按 BattlePassBaseConf[1].start=2022-10-31 06:00:00 +0800 和 28 天一期计算，当前是第 48 期。客户端展示路径 NewArenaBattlePassDialog -> ActArenaBattlePassData.getLvSkinReward/_updateSkinReward -> SkinToolTip 会从 client/assets/config/config.json 的 BattlePassBaseConf[1].skinReward[47] 取皮肤 3018，但 SkinConf[3018].attrs 为空，所以 tooltip 显示 [皮肤加成] 无，表现为这一期通行证皮肤奖励不完整。服务端发奖路径 activity_battlepassrewardclaim/recycleWarOrderRewardClaim -> domains/activity/battlepass.LoadBattlePassRowsAt -> appendDynamicArenaSkinReward 还优先读取 server/config/config1.json，该运行配置的 skinReward 只到第 30 期，导致第 48 期服务端动态发奖会兜到旧皮肤 2016；server/config/config.json 第 44-47 期也和客户端列表不一致。这是通行证皮肤奖励配置在客户端展示配置、服务端展示配置、服务端运行配置之间未同步，并且新追加皮肤缺少 attrs 的配置根因。
修复：补齐 client/assets/config/config.json、server/config/config.json、server/config/config1.json 三份配置：通行证 BattlePassBaseConf[1].skinReward 统一为客户端当前 50 期列表；第 48-50 期皮肤 3018/3019/3020 按同类传说通行证皮肤补 attrs=[{type:5,value:0.04},{type:7,value:0.04}]，并设置 attrOrder=3/isBook=1/bookPoint=3；服务端运行配置同步全部通行证皮肤的 SkinConf，保证展示和发奖使用同一皮肤 ID。
验证：已补充 TestPlan17ArenaBattlePassCurrentRoundSkinReward，固定第 48 期验证服务端发奖行会动态追加皮肤 3018；补充 TestPlan17ArenaBattlePassSkinRewardConfigsMatchClientAndHaveAttrs，验证客户端、服务端展示配置、服务端运行配置的竞技之路皮肤列表一致且每个通行证皮肤都有非空 attrs。已通过 go test -count=1 ./domains/activity/battlepass -run 'TestPlan17ArenaBattlePass'、go test -count=1 ./domains/activity/battlepass，并通过 jq empty client/assets/config/config.json server/config/config.json server/config/config1.json。2026-06-08 08:11/16:11 附近日志未搜到对应通行证领奖请求；本问题为确定性配置不一致和属性缺失，已用截图、客户端展示路径、服务端发奖路径、配置抽样和回归测试验证。
回归建议：打开竞技之路通行证当前第 48 期，确认 1 级付费奖励里显示皮肤 3018，点击 tooltip 显示攻击/生命 4% 加成而不是“无”；购买/解锁通行证并领取后确认获得的是 3018，对应武将皮肤拥有状态和战力刷新正常。再把本地时间或测试配置切到第 49/50 期，确认 3019/3020 同样有皮肤奖励和加成；抽查第 44-47 期不再出现客户端/服务端皮肤 ID 不一致。

问题18：
状态：验收通过
现象：俱乐部内成员红淬数量显示不对
预期：正常显示成员当前上阵红淬数量
截图：

根因：客户端俱乐部成员列表 LegionInfoDialog/LegionStarClubInfoDialog 显示成员红淬时读取成员摘要里的 custom.battle_red_quench_cnt（同源还有 red_quench_cnt/total_red_quench_cnt）；成员详情/阵容页展示的单武将红淬来自角色阵容/装备明细，所以截图中成员列表为 0，但点进详情能看到 16、18、15、16+4、18+3。服务端主查询 legion_getinfo 已经支持 ResolveMemberRedQuench，会通过 countRoleActiveTeamRedQuenches -> nightmarehelpers.CountActiveTeamRedQuenchesExact 按当前上阵 BattleTeam/NightmareTeam 的装备淬炼槽实时统计；但多个俱乐部管理/加入/改名/成员变更响应复用旧 helper resolveLegionMembersForClient，该 helper 调 ProcessMembersWithPresence 时第三个参数传 nil，导致成员摘要里的三处红淬字段都被写成 0。客户端收到这些响应后会覆盖当前成员缓存，于是列表显示 0。
修复：resolveLegionMembersForClient 改为传入 resolveLegionMemberRedQuench，所有复用该 helper 的俱乐部成员列表响应都按当前角色上阵阵容重新计算红淬；已有 legion_getinfo/legion_getinfobyid 路径保持同一套统计口径。未改客户端展示逻辑。
验证：已补充 TestResolveLegionMembersForClient_IncludesBattleRedQuench，构造上阵武将含 2 个红色淬炼槽，红测时旧 helper 返回 0，修复后 battle_red_quench_cnt/red_quench_cnt/total_red_quench_cnt 都为 2。已通过 go test -count=1 . -run 'TestResolveLegionMembersForClient_IncludesBattleRedQuench|TestLegionApplyListHandler_RefreshesStaleApplicantPower|TestLegionApplyJoinHandler_UsesDisplayPowerForQueuedApplicant'、go test -count=1 ./domains/legion/read -run 'TestHandleGetInfo_UsesResolversForMemberPowerAndRedQuench|TestBuildInfoByIDPayloadWithRedQuench_RecomputesMemberAndTotals|TestProcessMembersWithPresence_UsesOnlineResolver'、go test -count=1 ./domains/legion/read ./domains/legion/member。截图时间 2026-06-08 08:50/16:50 附近本地日志只搜到协程统计，没有对应 legion_getinfo 请求链；本问题已用截图、客户端字段读取、服务端成员摘要构造路径和回归测试验证。宽泛根包正则 go test -run 'Test.*Legion.*(Info|Member|Apply|Join|RedQuench|DisplayPower)' 仍撞到既有大航海/盐场排期用例失败（当前日期下 canEnterWar=false、报名阶段不符），与本次红淬 helper 无关。
回归建议：用一个俱乐部内成员准备当前上阵阵容含红色淬炼的账号，打开俱乐部详情成员列表，确认“红色淬炼”数等于该成员当前上阵 5 个武将装备红淬总数；点击成员头像进入详情/阵容页，确认列表总数与每个上阵武将红淬显示求和一致。再执行改公告/改入会限制/申请加入/同意加入/职位调整/踢人等会刷新俱乐部成员列表的操作，确认红淬数不会被刷新回 0。

问题19：
状态:验收通过
现象：端午消耗活动内产出的艾草开不出金艾草
预期：根据概率正常开出物品
截图：


根因：截图里背包道具是 艾草(5242)，客户端 ItemPanel 对 ItemType.PACK 调用 ItemModule.sendOpenPack -> ItemService.openPack({itemId:5242, number, index:0})，道具配置 ItemConf[5242].params=[1,90] 指向随机包 PackConf.90。服务端 item_openpack 在无特殊分支时会走 buildConfiguredOpenPackRewards(evotowerConfigRoot(), 5242, count, rng)，再按 PackConf.90.diamondPackRewardWeight 的 weight/总权重 加权随机发奖。客户端语言说明写的是金艾草 25%(5次必出)，其余奖励概率合计 75%，但实际 PackConf.90 中金艾草权重只有 2/10000=0.02%，其余奖励又被按去掉金艾草后的 75% 归一化到了接近 100%，所以 178 个艾草开不出金艾草并不是正常 25% 概率波动，而是服务端实际掉率配置和客户端说明完全不一致。
修复：按客户端说明的整张概率表重配 PackConf.90，server/config/config.json 和 client/assets/config/config.json 的 diamondPackRewardWeight、packShow 均改为说明概率乘 100 的权重，合计 10000：金艾草 2500，招募令 5/10 分别 500/250，随机红 10/20/25/40 分别 860/660/170/30，万能红 15/20/30/40 分别 190/350/140/10，铂金宝箱 2/5/10 分别 450/110/60，珍珠 2/5/8 分别 320/220/100，金砖 488/688/888/1888 分别 630/540/380/30，精铁 888/1088/1288/1888 分别 750/540/150/60。foldPackShow 改为同一概率表的分组权重合计；同步重新生成 client/assets/config/configc.bin，避免客户端开启压缩配置时继续读旧展示池。客户端语言说明本身已经是这张概率表，未改客户端业务代码。
验证：先补充 TestPlan13DragonBoatArtemisiaPackRewardsIncludeGold 的精确概率表断言，红测时失败在 PackConf.90.diamondPackRewardWeight reward 3|1013|5 weight = 297, want 220，证明当前配置不符合客户端说明；配置修复后通过 go test -count=1 ./internal/planconfig -run 'TestPlan13DragonBoatArtemisiaPackRewardsIncludeGold'、go test -count=1 ./internal/planconfig、go test -count=1 . -run 'TestBuildConfiguredOpenPackRewards_UsesItemParamsPackConf|TestBuildConfiguredChoosePackRewards_RejectsRandomPackIndex'。已通过 jq empty server/config/config.json client/assets/config/config.json server/config/config1.json，并用 BON 解码新 client/assets/config/configc.bin 确认 PackConf.90 实际池总权重 10000、金艾草权重 2500、折叠展示池总权重 10000。2026-06-08 09:25/17:25 附近本地日志只搜到协程统计，没有对应 item_openpack 请求链；本问题为确定性配置错误，已用截图、客户端触发路径、服务端开包路径、配置权重和回归测试验证。
回归建议：用测试角色准备大量 艾草(5242)，批量开启 100 个以上，确认奖励弹窗可正常出现 金艾草(5243)，背包中 5242 按开启数量扣减、5243 增加；再用较大样本统计金艾草占比应接近 25%，其余奖励占比和客户端说明一致。打开艾草道具详情，确认展示列表/折叠展示和说明文字一致。注意：当前服务端开包实现按权重随机发奖，未新增跨请求“5次必出”的持久化保底计数；如果产品要求严格兑现该括号文案，需要另做 5242 专用保底状态和回归测试。

问题20：
状态:验收通过
预期端午消耗内龙舟争霸活动ui直接删除
截图:

问题21:
状态:验收通过
预期:艾草兑换内金鱼铁血公换成金鱼回响 铁血母换成金鱼惊雷 且5条金鱼全部改成限购5

根因：艾草兑换活动 2505303 的 ExchangeActConf 仍保留旧配置，250530204/250530205 分别发放 11111 铁血公、11121 铁血母，且前 5 个金鱼兑换项 limitNum 都是 1；客户端兑换页直接读取该表显示限购，服务端 activity_exchange 也按同一表发奖和校验次数。
修复：已将 250530204.rewardId 改为 11211 回响，250530205.rewardId 改为 11221 惊雷，并将 250530201~250530205 的 limitNum 统一改为 5；同步更新服务端配置、客户端配置和 configc.bin。
回归建议：打开端午活动-艾草兑换，确认前 5 个金鱼兑换格均显示限购 5，第 4 个为回响、第 5 个为惊雷；准备足量艾草分别兑换 5 次应成功，第 6 次应返回次数不足；领取后背包获得的鱼灵 ID 应分别为 11211、11221。

问题22:
状态:验收通过
预期:确保玩家消耗金艾草和充值成功计入进度奖励活动内 消耗1个金艾草加10积分 累计充值积分按照VIP积分同步
截图:
根因：端午进度奖励页读取 activityRecord.common.2505305.task，客户端里道具积分是 EMMileStoneType.item=-2、已领奖节点是 -4。服务端原来只有活动面板展示，金艾草兑换 2505303 和真实充值发货没有把分数写入 2505305.task，也没有注册 activity_claimmilestone 领奖协议，所以截图里的“消耗金艾草获得积分/累计充值获得积分”一直保持 0，满足档位后也不能通过按钮领取。
修复：新增端午进度积分写入和领取链路：兑换活动 2505303 每消耗 1 个金艾草 5243 给 2505305.task[-1] 总积分加 10、task[-2] 道具积分加 10，道具积分封顶 2500；真实充值按实付分转元后给 task[-1] 加同等 VIP/充值积分，不补历史充值；activity_get 返回 activityRecord.common.2505305.task；注册并实现 activity_claimmilestone，一次领取当前已达成且未领取的档位，领奖状态写入 task[-4]。
回归建议：准备金艾草和测试充值订单，先消耗 100 个金艾草确认总积分加 1000、道具积分显示 1000/2500；再充值 1000 元确认总积分追加到 2000、累计充值积分按 1000 显示。达到 500/1000/2500 等档位后点击领取，应发放所有已达成未领取奖励并更新已领取状态；重复点击不能重复发奖。

问题23：
状态：已修复 待验证
现象：单周活动内 灵贝达标活动 做满两个档位后会重置刷新
预期：正常做满五个档位 一周最大只能做一轮 达标后可以正常领取每个档位的奖励
截图:

根因：灵贝消耗达标是增量周活动，服务端 pearlx 只拿到 roleID 后通过 findClientByRoleId 找在线 Client 才调用周活动进度写入；找不到本 Pod 的 Client 时直接跳过 DB 写入。同时 ensureWeekActivityRewardsForRole 又用累计统计 statistics.lb:4 去校准 activityRecord.week.10.num，记录缺失或基准异常时会把当前累计值当作本周起点，导致页面刷新后进度显示从 0 重新开始。
修复：周活动进度写入改为按 roleID 直接落库，在线 Client 只用于推送通知；灵贝达标从绝对累计统计校准中排除，只基于 activityRecord.week.10 的本周增量进度补发未发档位奖励。补充回归验证：灵贝周消耗 5000 后 num=5000、rounds=1、5 个档位 complete 均为 1，发 5 封档位奖励邮件，不滚到下一轮、不清零。
回归建议：在灵贝周准备 5000 个灵贝，连续淬炼/消耗到 500、1000、2500、3500、5000，确认页面进度不归零、当前奖励轮数始终 1/1，五个档位奖励邮件均收到；重新打开活动或重新登录后进度仍保持已完成状态，不出现 0/500、0/1000 刷新重置。

问题24：
状态：验收通过
现象：艾草兑换内所有奖励无法正常兑换 兑换无效
预期：可以正常使用金艾草兑换
截图：