bug反馈6.29 ¶

问题1：
状态：已修复（2026-06-30） 验收通过
备注：根因明确，已修服务端 server/domains/social/friend/action.go。好友同意逻辑原来只按硬编码 50 人上限判断，未叠加 VIP 好友数量加成（客户端好友上限显示为 frdNameListBase + FRIENDS_NUMBER_UP），导致达到 50 但仍有 VIP 扩容的玩家单独同意被服务端返回“好友列表已满/对方好友列表已满”，客户端未显式展示错误，看起来像点击无反应。批量同意在一个申请都未真正接受时仍返回成功，客户端会先清空本地申请列表，退出重进后从服务端重新拉到未处理申请，表现为恢复原状态。已补回归测试覆盖单个同意 VIP 上限、批量同意 VIP 上限、批量无实际接受时不返回假成功；验证 go test ./domains/social/friend、go test ./entry/social/friendentry 通过。说明：生产 6.29 17:14 附近日志未保留，已拷贝日志窗口中能看到相同命令存在 friend_agree code=8 对方好友列表已满，但未绑定到截图角色；“保存失败”只是入口层潜在风险，不作为本问题已定根因。
现象：游戏内好友申请 点击单独同意好友无反应 点击一键同意会成功 但是退出再进还是恢复刚刚的状态 无法正常同意添加好友
预期：单独点击同意正常生效 成功添加 点击一键同意可以成功添加所有申请
截图:

问题2：
状态：已修复（2026-06-30） 验收通过
备注：根因明确，已修服务端通行证/战令特权奖励链路。客户端客厅罐子“无限发条/未激活”显示读取 ROLE.privilege 中 PrivilegeType.BOTTLE_HELPER_TIME 对应的 Unix 秒到期时间；而服务端通行证领取 server/domains/activity/battlepass/recycle.go 原来只处理金币/钻石/物品/皮肤，漏处理配置中的 {type:20,itemId:101,value:1}，导致领取弹窗能显示无限发条但不会落到 role.privilege.101。同时支付发货链路原来把 privilege.101 写成 1，不满足客厅倒计时按时间戳判断的消费方式。现已统一改为发放/领取时写入并 patch privilege.101 = 当前时间 + 30天，已有未过期值会从原到期时间继续延长；补充回归测试覆盖战令领取落库、支付内存发奖和支付字段 patch。验证：go test ./domains/activity/battlepass -count=1、go test ./internal/payment -count=1 通过。说明：本地日志目录没有保留测试服账号 fafa/角色 791944 在 2026-06-29 20:45 的服务端协议日志，根因基于截图、客户端读取路径、服务端领取/支付代码和配置 {type:20,itemId:101} 的确定性链路定位。
测试服账号fafa 密码123456 ID：791944 时间：6.29 20:45
现象：购买通行证后 领取无限发条后 客厅内罐子无限发条显示未激活
预期：购买通行证后 成功激活无线发条 切正常生效
截图：

问题3：
状态：已修复（2026-06-30） 生产复核通过（2026-07-02，奖励已发；奖励争议转问题14/邮箱展示复核）
备注：根因已定死为服务端竞技场周赛季结算直写 Mongo，绕过在线 RoleStore 角色缓存。周一结算 settleArenaSeasonLevels 已把 Mongo 中 arenaScore 重置为 1000、按上周快照排名计算 arenaLevel，但在线玩家后续 arena_startarea / arena_getarearank / fight_startareaarena 都从缓存快照读取 arenaScore/arenaLevel；旧缓存仍是上周分数和场次，还可能通过旧 handler 保存/flush 覆盖结算结果，表现为周一仍显示 4963 分并停留入门场。生产一区本地归档日志从 2026-06-29 19:04 才开始，覆盖不到 00:01 周结算窗口；但能证明 facaizzz/100316514 在 2026-06-29 20:24:27 的 arena_getarearank 成功返回 rank=14 score=4963。已修：新增 RoleStore.ApplyPatchIfLoaded，只同步已加载在线角色、不 lazy-load 全服离线角色；settleArenaSeasonLevels 在 Mongo 更新成功后把同一份 arenaScore/arenaLevel/statisticsTime.area:arena:season:level patch 到在线缓存，防止查榜/进场继续读旧赛季状态。已补回归测试 TestRoleStore_ApplyPatchIfLoadedUpdatesOnlyLoadedRole、TestSyncArenaSeasonLevelLoadedRole_AppliesSettlementPatchToOnlineRole。验证：GOCACHE=/tmp/go-build go test ./internal/rolecachex -run 'TestRoleStore_ApplyPatch(IfLoadedUpdatesOnlyLoadedRole|DoesNotMutateCallerSet|KeepsBossFightReadable)' -count=1 和 GOCACHE=/tmp/go-build go test . -run 'Test(ArenaSeasonLevelSetOps_ResetsScoreForNewSeason|SyncArenaSeasonLevelLoadedRole_AppliesSettlementPatchToOnlineRole|ArenaSeasonNextLevel)' -count=1 通过。
复核记录（2026-07-02）：生产一区只读查询确认 100316514/facaizzz 当前 arenaScore=1000、arenaLevel=2，原“积分未清/未晋级”问题已恢复；mails 中 2026-06-29 00:01 的 竞技场赛季奖励 和 竞技场每日奖励 均存在且 state=3（附件已领取），2026-06-30、2026-07-01、2026-07-02 的每日奖励邮件也存在且 state=1（未领取）。因此“依旧没有发放奖励”不支持继续按问题3补代码或补发，后续若玩家仍看不到邮件，应按问题14或邮箱列表展示继续查客户端/邮件筛选截图。
正式服账号：facaizzz 密码：zzz1226 ID：100316514
现象：竞技场周一开启后 竞技场内玩家积分不会清零 且达到晋升要求 不会晋升竞技场场次等级 一直停留在入门场
预期：每周一所有人积分重置为1000 从头开始 根据上周各战场排名正常晋级场次等级
截图：

问题4：
状态：已修复（2026-06-30） 待正式服验收
备注：根因是服务端真实充值服排行发勋章只取充值前三，未按“累计充值大于3w”过滤，导致未达标玩家也会发放天启/天枢/星陨勋章。已在 server/compat_ws_bridge.go 的真实充值排行聚合中增加累计充值 amountCent >= 3000000 门槛，并补充回归测试 TestBuildRealRechargeTopRowsPipeline_RequiresThirtyThousandYuanBeforeRankLimit。验证：go test . -run 'Test(BuildRealRechargeTopRowsPipeline|GrantMedallionDirect|MedallionSystem|SystemMedallion|BuildFourSaintMedallion)' -count=1 通过。
现象：天启'无双至尊勋章 天枢'破界者勋章 星陨'征服者勋章 发放错误 未达标的玩家也有勋章
预期：根据区服世界播报 充值大于3w
本区充值第一名发放 天启'无双至尊勋章
第二名发放 天枢'破界者勋章
第三名发放 星陨'征服者勋章
截图：

问题5：（参考6.27 问题11）
正式服账号：facaizzz 密码：zzz1226 ID：100316514 时间：6.29号 20:14
状态：已修复（2026-06-30） 验收通过
根因：普通十殿 boss 面具领取使用 nightmareWeek.killAward 作为已领标记，该字段会随周重置；同时 persistNightmarePassProgress 给队伍全员写入面具解锁 key，队员也会被客户端识别为可领取。服务端 nightmare_takekillaward 也只看 maxLevel 和周字段，无法表达“终身一次 + 只有队长通关解锁”。
修复：新增 nightmareCharm.killAward 作为 boss 面具终身领取记录；领取时必须存在本周显式解锁 key，且终身已领则拒绝；通关后只给队长写面具解锁 key，周奖励 maxLevel 仍保留全员进度；第 9 关 bossId/可见层级 alias 同步处理。
验证：GOCACHE=/tmp/go-build go test . -run 'Test(BuildNightmareKillAwardForRole_|BuildNightmareOnceRewardForRole_DoesNotInferClaimedFromMaxLevel|ClaimNightmareKillAwardRejectsLifetimeClaimedMask|ClaimNightmareKillAwardRequiresExplicitUnlockKey|ClaimNightmareKillAwardPersistsLifetimeMaskClaim|PersistNightmarePassProgressUnlocksMaskOnlyForLeader|PersistNightmareHiddenBossProgress_GrantsRewardBeforeMarkingClaimed|ClaimNightmareWeekRewards_|ClaimNightmareTurnRewardTimes_|BuildNightmareWeekAwardForRole_)' -count=1；GOCACHE=/tmp/go-build go test ./domains/pve/nightmare -run 'TestHandle(TakeKillAward|ClaimCharm)' -count=1；GOCACHE=/tmp/go-build go test ./internal/rolecachex -run 'Test.*Nightmare|TestRoleStore_ApplyPatch' -count=1。
现象：十殿内 每次通关都可以领取一次1-9的boss面具奖励
预期：一个角色终身只能领取一次每一关的面具奖励 无法重复领取 且十殿面具只有队长通关后才可以解锁 队员通过无法解锁
截图：

问题6：（参看6.27 问题12）
状态：已修复（2026-06-30） 验收通过
根因：服务端 buildNightmareTurntableRewardForClient 把本周转盘历史展开成 confId:index 形式的 key，例如 9:1、9:2；但客户端协议 GDNightmareWeek.turntableReward 定义是 Map<Number, Array<GDRewardData>>，客户端解码 Number key 时对非数字字符串执行 +key || 0，多个非数字 key 会合并覆盖成同一个 0，所以列表最后只剩一个奖励格。
修复：服务端仍按已抽奖励次数展开历史，但返回递增数字字符串 key（1、2、3…），保持客户端 Number Map 可唯一解码；奖励内容仍由原始 confId 查配置生成。
验证：生产日志 server/runtime/logs/prod-1-bugfan-20260629/cbbb36602e1dc12f105df431fb6fed52d8e83c0ede4e855c525a965c944af9a9-json.log.29 显示角色 100316514 在 2026-06-29 20:18:55 至 20:20:09 共完成 8 次 nightmare_clickturntable，说明问题是显示历史合并，不是抽奖未记录；已新增回归测试覆盖重复奖励必须返回多个数字 key。测试：GOCACHE=/tmp/go-build go test . -run 'Test(BuildNightmareTurntableRewardForClient_|ClickNightmareTurntable_|ClaimNightmareWeekRewards_|ClaimNightmareTurnRewardTimes_|BuildNightmareWeekAwardForRole_|BuildNightmareKillAwardForRole_|BuildNightmareOnceRewardForRole_DoesNotInferClaimedFromMaxLevel|ClaimNightmareKillAward|PersistNightmarePassProgressUnlocksMaskOnlyForLeader|PersistNightmareHiddenBossProgress_GrantsRewardBeforeMarkingClaimed)' -count=1；GOCACHE=/tmp/go-build go test ./domains/pve/nightmare -run 'TestHandle(TakeKillAward|ClaimCharm)' -count=1；GOCACHE=/tmp/go-build go test ./internal/rolecachex -run 'Test.*Nightmare|TestRoleStore_ApplyPatch' -count=1。
正式服账号：facaizzz 密码：zzz1226 ID：100316514 时间：6.29号 20:20
现象：十殿转盘抽奖后本周已获得奖励显示不正确且只显示一个
预期：显示本周抽奖到的所有奖励
截图：

问题7：
状态：已修复（2026-07-02） 待测试服复验
备注：皮肤图鉴可点亮 但是无法佩戴 皮肤未点亮。二次根因确认：当前测试库中 791944/fafa 已有 heroes.118.skin.3018 和 skinBook.3018，不是未到账；客户端可佩戴列表按 HeroConf.<heroId>.skinList 枚举，而 skin_3018/3019/3020 虽存在 SkinConf/AvatarConf，但未挂到 118/119/120 的 skinList，所以图鉴可亮、领奖弹窗可显示，皮肤页仍不能选择佩戴。
根因：activity_battlepassrewardclaim 领取通行证皮肤时，服务端会把动态皮肤 skin_3018 解析成 heroId=118 并写入 heroes.118.skin.3018 / heroes.118.useSkin；但主响应只稳定返回 reward 和 activity.warOrderActivityInfo，英雄皮肤状态依赖 GetOptimizedRole/战力刷新 delta 顺带返回。客户端奖励弹窗读取 resp.reward，所以会显示“获得新皮肤”；可佩戴判断读取在线 ROLE.heroes[118].skin[3018]，当本次响应没有显式合并这个 heroes delta 时，皮肤页仍判断未拥有。
修复：服务端 ClaimRecycleWarOrder 在完成皮肤发放和持久化 patch 后，按本次实际发放的 skin reward 生成最小 role/roleInfo 英雄 delta，显式返回 heroes.<heroId>.skin.<skinId> 和 useSkin，不再依赖优化角色视图是否即时带出新皮肤。二次修复补齐 server/config/config.json、client/assets/config/config.json、client/assets/config/configc.bin：HeroConf.118.skinList += 3018、HeroConf.119.skinList += 3019、HeroConf.120.skinList += 3020；并已重新发布本机测试服，镜像 xianyu-game-server:latest 创建时间 2026-07-02 09:37:05，/api/health 和 /api/ready 通过。
验证：截图链路已确认领取弹窗为 skin_3018，后续赵云皮肤页仍灰显未拥有；客户端代码确认弹窗读 reward，佩戴判断读 ROLE.heroes[*].skin 和 HeroConf.skinList。测试服日志显示文档 2026-06-29 20:45 的领奖 trace 实际是 roleId=151830 account=fafa，791944 后续也已拥有 3018。已新增回归测试覆盖 GetRolePayload 返回旧英雄视图时，领奖响应仍必须带出皮肤 delta，并新增 TestPlan17ArenaBattlePassSkinRewardsListedOnHeroes 防止战令皮肤未挂到武将皮肤列表。测试：GOCACHE=/tmp/go-build go test ./domains/activity/battlepass -run 'TestPlan17ArenaBattlePass(CurrentRoundSkinReward|SkinRewardConfigsMatchClientAndHaveAttrs|SkinRewardsListedOnHeroes)|TestPlan20ArenaBattlePassRuntimeSkinRewardConfigsHaveDisplayMetadata|TestClaimRecycleWarOrder_ClaimsNewArenaDynamicSkinReward' -count=1 通过；client/assets/config/configc.bin 已用 bon 编码重生成并反解确认 118/119/120 列表包含 3018/3019/3020。
测试服账号fafa 密码123456 ID：791944 时间：6.29 20:45
现象：购买通行证后 领取奖励 皮肤显示领取成功 但是实际未到账
预期：皮肤正常到账可以正常佩戴
截图：

问题8：
状态：已修复（2026-06-30） 验收通过
根因：十殿罗盘 UI 的“剩余寻宝次数”不读背包入梦铃数量，而是读服务端 weekAward.turntableLeftCnt。生产日志候选时间线显示 roleId=100631781 在 2026-06-29 20:49:43 领取 8 档周奖励，服务端发放了 8 份 itemId=1037,value=5（共 40 个入梦铃），但领取前状态已经是 bookScore=40 / turnRewardTime=40 / turntableLeftCnt=0 / turntableReward=[]，旧逻辑只按 bookScore - turnRewardTime 计算新增次数，结果 pendingScore=0，因此 addTurntableCnt=0，回包和后续 nightmare_getroleinfo 都继续显示 turntableLeftCnt=0。
修复：claimNightmareWeekRewards 不再只信任 turnRewardTime，改为按总权益校验并补缺口：应得寻宝次数 = effectiveBookScore / NightmareEveryFiveGetOne，已实现次数 = turntableLeftCnt + turntableReward 已抽次数，缺多少补多少到 nightmareWeek.turntableLeftCnt；同时把 turnRewardTime 补到应得积分，避免后续重复兑换。这样历史/异常状态下即使 turnRewardTime 已推进但实际剩余/已抽次数丢失，领取周奖励时也会恢复可抽次数。
验证：截图显示罗盘/转盘页中心 0/5、剩余寻宝次数 0；客户端代码确认罗盘次数读 roomData.nightmareWeekInfo.turntableLeftCnt，不是 ROLE.items。日志候选 roleId=100631781 完整呈现“发 40 个入梦铃但 addTurntableCnt=0，后续仍 turntableLeftCnt=0”的服务端根因。已新增回归测试复现 bookScore=40 / turnRewardTime=40 / turntableLeftCnt=0 / turntableReward=[] 后领取 8 档奖励必须补 8 次寻宝。测试：GOCACHE=/tmp/go-build go test . -run 'Test(ClaimNightmareWeekRewards_(RepairsMissingCompassTimesWhenScoreAlreadyConsumed|BackfillsCompassTimesFromMaxLevel|ConcurrentClaimsOnlyPaysOnce)|ClaimNightmareTurnRewardTimes_EightBellGroupsGrantEightChances|ClickNightmareTurntable_AppliesRewardAndReturnsRoleDelta|BuildNightmareTurntableRewardForClient_UsesNumericKeysForRepeatedRewards|ClaimNightmareKillAward|PersistNightmarePassProgressUnlocksMaskOnlyForLeader)' -count=1；GOCACHE=/tmp/go-build go test ./domains/pve/nightmare -run 'TestHandle(TakeKillAward|ClaimCharm)' -count=1；GOCACHE=/tmp/go-build go test ./internal/rolecachex -run 'Test.*Nightmare|TestRoleStore_ApplyPatch' -count=1。
现象：通过十殿后领取完十殿转盘入梦铃 但是缺无法抽奖 显示抽奖次数为0
预期：领取完入梦铃后 没5个入梦铃可以转盘抽奖一次 （十殿队员通过后也可正常领取奖励抽奖 每周一次 面具是需要队长）
截图：

问题9：
状态：已修复（2026-06-30） 验收通过
正式服账号：facaizzz 密码：zzz1226 ID：100316514
现象：日活动彩玉狂欢 彩玉灵矿内 奖励领取过后 还是显示待领取的ui
预期：领取完奖励后正常显示已领取的ui
处理记录：已定位为彩玉灵脉领取状态字段协议不一致。客户端读取 Statistics.QuenchCarnivalClaimed=qc:cl，服务端历史写入/回包使用 qc:c；生产只读查询确认 100316514 当前有 qc:l=5、qc:c=5，缺少 qc:cl，导致 UI 按未领取显示。已修复服务端 activity_claimquenchcarnivallevel 写入/回包 qc:cl 并兼容历史 qc:c 防重复发奖；activity_get 打开活动时也会追加最小 role/roleInfo.statistics delta 帮在线客户端刷新。验证：GOCACHE=/tmp/go-build go test ./domains/activity/quenchcarnival -count=1、GOCACHE=/tmp/go-build go test ./domains/activity/read -run 'TestHandleActivityGet_ReturnsQuenchCarnivalClaimedClientDelta|TestHandleActivityGet_DoesNotLogBattlePassDiagByDefault|TestHandleActivityGet_ParseFailure' -count=1、GOCACHE=/tmp/go-build go test ./entry/activity/activityentry -count=1。
截图：

问题10：
状态：暂跳过（2026-07-01，已记录初步证据）
备注：测试服：账号rty520520520 密码 520520 ID：100243669 时间7月1号 1:40 （跳过战斗必输 不跳过赢了判定输）
备注：已看截图和生产一区本地轮转日志。截图确认入口为“星级挑战”第 1 关“秦广王”，结算层显示“挑战失败”，背后可见本方仍有血量；客户端路径为 NightmareStarPanel -> NightmareStarDeployDataAdapter.sendFight -> NMExtService.startBoss，失败弹窗走 BattleType.nMStarBoss 的 CommonBattleFailTipB。日志在 2026-06-29 22:42:05 命中 nmext_startboss roleId=100243669 bossId=1，服务端返回 isWin=false、newStars=[]；runGenieFallbackBattle 同一战斗 leftHP=0 rightHP=333555453938 simRound=11，battleData.result.acceptTeam 与右侧秦广王队伍均显示 boss 队伍未被击杀。当前证据更像战斗实际被服务端判负/配置或战斗展示理解差异，不是保存失败；按要求先跳过，后续如继续需单独核对回放/战斗引擎结果和星级挑战胜负规则。
现象：星级挑战内 攻打第一关 秦广王boss赢了判定输
预期：赢就是赢 所有boss都不会赢了判定输
截图：

问题11：
状态：已修复（2026-06-30） 验收通过
备注：根因已定死为服务端俱乐部赛车日志归属错误。收车弹窗 CargoRaidGetRewardDialog 通过 car_detail 读取 logs[].roleInfo 作为“遭袭玩家/袭击者”展示；服务端 Runtime.Claim 原先把车主收车记录写入 battle 日志类型 1，roleInfo 是车主自己，同时 Runtime.Raid 只给攻击方写 battle 日志，没有给被袭击车主写攻击者日志，Runtime.Detail 还返回当前角色所有 battle 日志而非当前车日志，导致收车详情可能显示“自己被自己袭击”或串入其它车记录。已修：收车不再写 battle 日志；抢车成功/失败时给被袭击车主写防守视角日志（roleInfo 为真实攻击者，结果转为 defenseWin/defenseLose）；car_detail 只返回当前 carId 的 battle 日志。生产一区本地轮转日志缺失关键发车/收车窗口，只能看到 facaizzz/100316514 的 car_getrolecar 快照中 4 辆车 raided=1，无法从日志还原具体袭击者；代码路径和回归测试已覆盖该确定性根因。已补 TestRuntimeClaimDoesNotCreateSelfRaidDetailLog、TestRuntimeDetailShowsOnlyRaidersForRequestedCar，验证 go test ./domains/legion/cargoraid -count=1 通过。
正式服账号：facaizzz 密码：zzz1226 ID：100316514
现象：俱乐部赛车内 收车时会显示自己被自己袭击
预期：只会被别的玩家袭击 且正常显示袭击玩家
截图：

问题12：
状态：已修复（2026-06-30） 验收通过
备注：根因已定死为服务端响应体过大。生产一区日志中 facaizzz/100316514 的 artifact_lottery 24 次平均回包约 942KB、最大 953KB，artifact_exchange 7 次平均约 930KB、最大 951KB，规模接近 role_getroleinfo；handler 多数为 100-470ms，sendEnqueueMs 近 0，没有网络写阻塞证据。客户端回调实际只读 reward、鱼竿数量、钓鱼积分、免费次数/时间，但全量 role 合并会触发 SyncItemList/SyncHeroList，神器模块随即全量遍历 items/heroes/pearlMap 并重排，表现为转圈/卡顿。已修 artifact_lottery 和 artifact_exchange：不再返回全量 roleData["role"]，改为只返回钓鱼所需 delta（普通/高级鱼竿、奖励物品、artifact:point、ar:normal:lo:cnt、钓鱼统计时间、必要 artifactBooks）。已补 TestHandleLottery_ReturnsFishingDeltaInsteadOfFullRole、TestBuildFishingRoleDelta_IncludesOnlyFishingFields，验证 go test ./internal/artifactx -count=1 与根包编译通过。
正式服账号：facaizzz 密码：zzz1226 ID：100316514
现象：正式服客厅内钓鱼或者点击领取金鱼竿 会反应很慢 卡顿 有时会转圈
预期：客厅内钓鱼 领取金鱼竿不会延迟卡顿
截图：

问题13：
状态：已修复（2026-07-01，生产数据重置按更新时处理） 验收通过
备注：已修 server/client 两份 config.json：端午消耗活动 2505301、艾草兑换 2505303 时间改为 2026-07-01 00:00:00 到 2026-07-31 23:59:59；艾草兑换前 5 档改为 11191 公琴心、11201 母琴心、11151 巨灵、11161 剑胆公、11171 剑胆母，限购仍为 5。已补充 TestPlan20260629DragonBoatArtemisiaExchangeJulyCycle，验证 go test ./config -run 'TestPlan202606(01|29)' -count=1 通过。剩余：如果生产继续复用活动 ID，需要清理/迁移玩家 activityRecord.common.2505301/2505303，否则老玩家的任务领取和兑换限购记录不会仅靠配置自动重置。
预期：端午活动艾草兑换内 5条金鱼分别更换为：（公琴心 母琴心 巨灵 剑胆公 剑胆母） 限购5
6月30号凌晨12点 重置刷新端午消耗活动 重置刷新艾草兑换里物品限购次数
活动时间从7月1号0:00-7月31号23:59
所有玩家可重新做消耗任务 领取奖励 （确保所有玩家一个周期内只能做一次任务 活动周期内不会二次刷新活动）

截图：

问题14：
状态：已核查，待下个结算点验证（2026-07-01，暂不改代码）
现象：正式服内竞技场每日和赛季奖励不发放
预期：每日奖励根据根据对应场次及排名每天0点发放到邮箱 赛季奖励根据对应场次及排名每周日0点发放到邮箱
截图：

核查记录（2026-07-01）：

• 截图顶栏 uid=28991，生产一区日志可对应到 roleId=100450081、account=EM18537；该角色在 2026-06-29 23:20:50 创建，晚于 2026-06-29 22:00 的每日奖励快照，因此不应出现在 2026-06-30 00:01 的上一轮每日发奖名单。
• 生产日志显示 2026-06-29 22:01:43 每日奖励快照执行成功：rewardType=1 stamp=1782741600 snapshotted=12126 skipped=0 ranked=12126；2026-06-30 00:01:00-00:03:29 每日奖励邮件发放执行，汇总 sent=5757 skipped=4817，说明“每日奖励全服不发”与日志不符。
• 客户端奖励页只展示 ArenaGift.dayReward/weekReward，实际发奖依赖服务端定时邮件；截图时间为 2026-06-30 15:07，应等待 2026-06-30 22:00 快照和 2026-07-01 00:01 发放验证。
• 当前拷贝日志未覆盖赛季 rewardType=2 的发奖窗口，赛季奖励暂无法用日志闭环；不标记已修复，后续需在周结算窗口或补充生产日志验证。

问题15：
状态：已修复（2026-07-01） 验收通过
预期：充值内积天好礼累计天数增加到60天 每天对应奖励如下
累计充值31天 彩玉*100

累计充值32天 彩玉*110

累计充值33天 彩玉*120

累计充值34天 彩玉*130

累计充值35天 彩玉*140

累计充值36天 彩玉*150

累计充值37天 彩玉*160

累计充值38天 彩玉*170

累计充值39天 彩玉*180

累计充值40天 珍珠*400

累计充值41天 红玉*10

累计充值42天 红玉*10

累计充值43天 红玉*10

累计充值44天 红玉*10

累计充值45天 红玉*15

累计充值46天 红玉*15

累计充值47天 红玉*15

累计充值48天 红玉*15

累计充值49天 红玉*15

累计充值50天 彩玉*1000

累计充值51天 蓝玉*200

累计充值52天 蓝玉*210

累计充值53天 蓝玉*220

累计充值54天 蓝玉*230

累计充值55天 蓝玉*240

累计充值56天 蓝玉*250

累计充值57天 蓝玉*260

累计充值58天 蓝玉*270

累计充值59天 蓝玉*280

累计充值60天 复活丹*10

截图：

修复记录（2026-07-01）：

• 根因：积天好礼不是代码 30 天上限，服务端累计天数和 addUpCharge 都支持继续增长；实际是客户端 DayBuyConf 展示配置、服务端 config1.json fallback、以及 DB 迁移源 daybuy_rewards.json 均只配置到第30天，导致页面只显示到30天，31-60天也无法通过配置领取。
• 已补齐第31-60天配置：client/assets/config/config.json、client/assets/config/configc.bin、server/config/config.json、server/config/config1.json、server/config/daybuy_rewards.json。
• 奖励ID：彩玉=1023、珍珠=1013、红玉=10003、蓝玉=10002、复活丹=1017。
• 验证：jq empty client/assets/config/config.json server/config/config1.json server/config/config.json server/config/daybuy_rewards.json 通过；go test ./config ./domains/activity/claim -count=1 通过；configc.bin 已用 bon 解码确认 DayBuyConf 共60档且第60天为复活丹*10。
• 生产生效：daybuy_rewards_config 是 DB 优先，发版后还需要通过 GM 迁移 /gm/api/migrate-daybuy-rewards 或等价 upsert 将31-60写入生产 DB；客户端侧需要同步新 config/configc 热更或重新打包，否则页面仍只显示到30天。

问题16：
状态：已修复（2026-07-02） 验收通过
现象：俱乐部赛车内黄金赛车发车奖励不是区间随机奖励
预期：奖励应该是区间奖励 每次刷新的奖励数量都不相同 具体奖励如下
招募令：最低40最高80
白玉：最低4000-最高10000
彩玉：最低20最高40
红将万能碎片：最低50最高80
金砖：最低4000最高8000
梦魇晶石：最低10000最高15000
高级房卡：最低1最高5
截图：

修复记录（2026-07-01）：

• 根因：客户端赛车发车预览只展示服务端 GDCar.rewards[].value，没有区间随机逻辑；服务端 car_refresh 原来调用 defaultRewardsByColor，rng=nil 时固定取配置下限，所以每次刷新看到的奖励数量固定。同时 FreeCar.6/99.SendRewards 仍是旧区间，和本次策划预期不一致。
• 已修服务端：car_refresh 刷新黄金/传奇车时直接按当前车和角色种子随机生成奖励并存入 car.rewards；car_send 如果车上已有刷新出的奖励则保留，不再发车时二次随机，保证预览和最终发车奖励一致。
• 已修配置：server/config/config.json、client/assets/config/config.json 的 FreeCar.6/99.SendRewards 改为招募令40-80、白玉4000-10000、彩玉20-40、红将万能碎片50-80、金砖4000-8000、梦魇晶石10000-15000、高级房卡1-5。
• 生产日志说明：2026-06-30 10:07 附近生产一区日志能看到 car_refresh/car_send 请求，但日志未打印 reward 数组，无法直接从日志反推奖励数值；根因由截图、客户端展示路径、服务端刷新/发车代码和配置闭环确认。
• 验证：GOCACHE=/tmp/go-build go test ./domains/legion/cargoraid -run 'Test(RandomRewardsForCar_UsesGoldenCarRanges|RuntimeRefresh_RollsGoldenCarPreviewRewardValues|RuntimeSend_PreservesRefreshedCarRewards|RuntimeSendRefreshClaim|DefaultRewardsByColor_UsesConfiguredFreeCarRewards|RefreshWithBigCarPrivilege)' -count=1 通过；GOCACHE=/tmp/go-build go test ./internal/planconfig -run 'Test(CargoRaid|Plan13DragonBoatFestivalConfigMirrors)' -count=1 通过；GOCACHE=/tmp/go-build go test ./domains/legion/cargoraid ./internal/planconfig -count=1 通过；jq empty server/config/config.json client/assets/config/config.json 通过。
• 验收不通过复核（2026-07-02）：测试服运行镜像和 test-runtime/config/config.json 都早于 2026-07-01 修复，导致 2026-07-01 17:31 的 791944/fafa 仍跑旧代码/旧配置；Mongo 中 cargoRaid.carDataMap.791944_1.rewards 已持久化旧固定边界值 [40,4000,20,50,4000,15000,1]。已执行 deploy/bin/update.sh test 重新发布本机测试服，运行目录 test-runtime/config/config.json 与 server/config/config.json sha256 一致，FreeCar.6/99 为新区间；容器 xianyu-test-game-server 使用 2026-07-02 09:37:05 新镜像且 health/ready 通过。为避免旧数据继续污染验收，已仅在测试库把未发车 791944_1 的 rewards 更新为当前区间内样本 [72,8731,31,67,6950,12640,3]，sendAt=0 保持不变。

问题17：
状态：服务端已修复，待正式服验收
正式服账号：facaizzz ID：100316514 时间：7.2号 0:25
现象：游戏内点击充值 和充值内部的签到四卡领取奖励都特别卡 会出现转圈圈
预期：点击充值和内部功能不会卡顿
截图：

修复记录（2026-07-02）：

• 根因：充值活动内部多个领奖接口成功后返回整份 role，大号会把英雄/道具/养成等大字段一起下发。历史生产日志中 system_signinreward 平均回包约 509KB、最大约 1.17MB；card_claimreward 平均约 354KB、最大约 678KB；charge_claimaddup 平均约 249KB、最大约 665KB。客户端领奖后只需要 reward 和少量状态字段，整 role 合并会放大网络、编码和客户端刷新卡顿。
• 已修服务端：system_signinreward 改为只返回 signInReward、奖励影响到的 gold/diamond/items；card_claimreward 改为只返回 cardTime、奖励影响到的资源/道具；charge_claimaddup 改为只返回 addUpCharge、奖励影响到的资源/道具。不再调用 full role 构建器。
• 补充核查：充值活动入口 activity_get 历史回包约 5-7KB，未见同类大响应；本轮只修服务端领奖路径，不改客户端。若正式服验收仍反馈“点击充值入口”卡顿，需要再取 2026-07-02 00:25 附近实时日志/客户端状态继续拆入口链路。
• 验证：新增回归测试锁定领奖接口不再重建完整 role；GOCACHE=/tmp/go-build go test ./domains/commerce/pay ./domains/activity/claim ./domains/legion/cargoraid -count=1 通过；GOCACHE=/tmp/go-build go test . -run 'Test(SystemSignIn|BuildSystemSignIn|NextSystemSignIn|ResetSystemSignIn|NormalizeSystemSignIn)' -count=1 通过。
• 测试服发布：已执行 deploy/bin/update.sh test 更新本机测试服；2026-07-02 11:48 复查 xianyu-test-game-server 和 4 个 battle-worker 均 healthy，/api/health 返回 OK，/api/ready 返回 MongoDB/Redis ready。

问题18：
状态：服务端已修复，待正式服验收
正式服账号：facaizzz ID：100316514 时间：7.2号 0:31
现象：俱乐部赛车内点击排行 会出现转圈卡顿
预期：点击排行不会卡顿
截图：

修复记录（2026-07-02）：

• 根因：car_getgrouprank 进入 GroupRankBoard 后按军团聚合排行，但每个军团都调用 Runtime.legionMeta，旧逻辑每次都通过 JlbService.GetRole(legionID) 串行查 Mongo legion 集合。历史生产日志显示 car_getgrouprank 平均 handlerMs=8578、最大 13132，回包只有约 6.7KB，瓶颈不是响应大小而是排行请求中的串行数据库查询。
• 已修服务端：Runtime.legionMeta 增加按 legionID 的 10 秒 TTL 本地缓存，重复打开排行或同一批排行构建时复用军团元信息；SetLegionLoader 时清空缓存，避免测试/初始化切换 loader 后读旧数据。
• 验证：新增回归测试证明同一 Runtime 短时间重复 GroupRankBoard 不会重复调用同一 legion loader；旧实现下 loads[7] 为 4，新实现为 1。GOCACHE=/tmp/go-build go test ./domains/legion/cargoraid -run TestRuntimeGroupRankBoard_ReusesLegionMetaLoaderWithinRuntime -count=1 通过；GOCACHE=/tmp/go-build go test ./domains/legion/cargoraid -count=1 通过。
• 测试服发布：已执行 deploy/bin/update.sh test 更新本机测试服；2026-07-02 11:48 复查 xianyu-test-game-server 和 4 个 battle-worker 均 healthy，/api/health 返回 OK，/api/ready 返回 MongoDB/Redis ready。

问题19：
状态：未修复（本轮按要求不改客户端）
预期：取消游戏内名人堂和设置红色感叹号提醒ui

分析记录（2026-07-02）：

• 根因定位为客户端红点绑定：左侧入口聚合了名人堂/设置红点，且名人堂游客红点逻辑会持续触发；未发现需要服务端数据修复的根因。
• 用户要求“先不改客户端”，因此本轮跳过，等待允许改客户端时再处理。