bug反馈 2026.4.29 ¶

问题1:
状态：已修复
现象：点击赐福后 无法正常成功赐福给被赐福武将
预期：选择赐福淬炼后可以成功赐福给被赐福武将
根因：客户端淬炼赐福按装备 curQuenchId 区分正反面，赐福列表、关闭赐福、战斗触发和个人/主页展示分别读取服务端下发的 enchantUId/enchantUId2、当前面 quenches、heroEBuffMap 和战斗 battleData。服务端旧实现把正反面赐福当成同一套映射处理，且关闭/设置赐福后没有按客户端字段口径立即同步当前面状态；战斗侧也缺少按“被赐福装备当前佩戴面”计算红色赐福属性的完整链路，导致页面显示和实际战斗都可能不一致。
修复：服务端赐福链路按装备部位 + 正反面独立保存和读取，设置/关闭赐福后返回客户端需要的当前面装备字段并同步角色缓存；战斗开始时按被赐福方当前佩戴面触发赐福，从赐福方对应面红色词条中按规则随机生效，且同场战斗去重属性类型；个人资料/主页相关读路径使用同一套赐福映射生成展示数量。
验证：已按客户端协议字段链路复核 equipment_enchant/equipment_cancelenchant、heroEBuffMap、战斗赐福触发日志和正反面独立规则；后续如复测仍异常，以新日志继续定位具体字段。
截图：

淬炼赐福具体规则

1. 赐福条件
   (1) 赐福的装备需解锁 5 个淬炼孔位，可选择该装备任意一面的淬炼属性，赐福给开启淬炼的指定装备。
   (2) 被赐福的指定装备需解锁淬炼系统，方可接收赐福。
2. 赐福限制
   (1) 每件装备部位的每一面，仅可被赐福 1 套淬炼属性。
   (2) 赐福属性仅在被赐福装备当前佩戴的一面生效。
3. 赐福触发
   (1) 战斗开始时，携带淬炼赐福的咸将，每个被赐福的装备部位都有概率随机生效 1 条红色品质的赐福属性。
   (2) 单个部位赐福的生效概率，由赐福方该部位淬炼属性中红色品质属性的总数量决定，具体概率如下：
   1 个红色属性：20%
   2 个红色属性：40%
   3 个红色属性：60%
   4 个红色属性：80%
   5 个红色属性：100%
4. 赐福生效规则
   (1) 若该部位赐福判定生效，则从 5 个孔位的红色属性中随机选取 1 条生效。
   (2) 战斗开始时，咸将可获得的赐福属性类型不会重复。
   （例如：太史慈（被赐福方）的武器部位赐福生效了攻击属性，则剩余 3 个装备部位的赐福不会再生效攻击属性）
5. 赐福效果计算
   赐福属性最终效果 = 赐福属性基础属性值 × 赐福属性修正百分比
   (1) 赐福基础属性值：取自赐福方装备该淬炼属性自身的属性数值，各属性上限参照前文「属性与最大加成」。
   (2) 赐福属性修正百分比：根据属性类型固定生效，不同属性对应修正百分比如下：
   攻击：75%
   血量：75%
   防御：75%
   速度：100%
   破甲：100%
   破甲抵抗：60%
   精准：50%
   格挡：50%
   减伤：100%
   技能伤害：100%
   暴击：40%
   暴击抵抗：40%
   爆伤：100%
   爆伤抵抗：100%
   免控：25%
   眩晕免疫：10%
   冰冻免疫：10%
   沉默免疫：10%
   流血免疫：15%
   中毒免疫：15%
   灼烧免疫：15%

问题2：
状态：已修复
现象：图鉴内每个武将领取到满星最后一个星级时可以无限领取图鉴分
预期：不可以无限领取 每个星级领取一次
根因：客户端图鉴升级按钮只在 hero.star > hero.bookStar 时允许继续领取；服务端 book_upgrade 只校验 book_config.star 配置数组长度，未校验武将当前实际星级。由于服务端配置里存在较长的占位星级数组，满星最后一个星级领取后仍会返回成功并继续增加图鉴分。
修复：服务端 UpgradeHeroBook 增加实际武将星级边界校验，bookStar >= hero.star 时返回最大等级错误，不再发放图鉴分；仍保留配置数组长度校验作为配置上限保护。
验证：GOCACHE=/tmp/go-build-cache go test ./domains/growth/book
截图：

问题3：
状态：已修复
现象：创建十殿房间后 在退出十殿界面从弹窗点击进入十殿 可以直接开启对战 人数无需大于两人 不需要枕头可直接开启（队员也是一样）
预期：十殿开启房间对战必须人数等于或者大于两人 且每对战一次消耗一个对应的枕头 从外面弹窗点击进入应该是组队界面 不应该直接开启 （必须房主点击开启才会开起对战）
根因：客户端十殿入口复用房间/组队链路，开始按钮只负责发起 matchteam_start/房间开始相关协议，真正能否开战必须由服务端按队伍人数、准备状态和消耗道具兜底。旧服务端缺少十殿专用的服务端前置校验和开战扣道具保护，外部弹窗恢复房间后可能绕过客户端界面限制直接进入开战流程。
修复：服务端在十殿 matchteam_start 和自动倒计时启动前统一调用 validateNightmareTeamCanStart，要求队伍至少 2 人、非房主成员已准备、所有成员拥有本层所需枕头；真正开始战斗前再由 ConsumeStartItemsIfNeeded 校验并扣除对应道具，同时 lookupNightmareRoomForRead 不再为单人读路径创建可开战房间。
验证：GOCACHE=/tmp/go-build-cache go test . -run 'TestValidateNightmareTeamCanStart_RequiresTwoMembersBeforeRoleService|TestLookupNightmareRoomForRead_DoesNotCreateSoloRoom'。
截图：

问题4：
状态：已修复
现象：功法内 抽出的功法直接分解和在背包分解功法后 不返还相应残卷
预期：分解功法后返还相应的残卷
根因：客户端分解功法调用 legacy_resolve 后读取 roleLegacy.exp 和 reward；服务端只按 resolveExp 增加宝箱经验，宝箱满级时没有按客户端规则把分解收益转成功法残卷，也没有返回客户端会读取的 reward 数组和 role.items 同步，导致满级分解看不到残卷返还。
修复：服务端在宝箱满级时将分解收益发放为功法残卷 37007，返回 reward、role/roleInfo.items 和可读的 roleLegacy.exp；未满级仍增加宝箱经验并返回空 reward 数组，避免客户端协议字段缺失。
验证：GOCACHE=/tmp/go-build-cache go test ./domains/growth/legacy
截图：

问题29：
状态：已修复
现象：咸王梦境内 一开始自动上场了5个武将 玩家无法更改选择武将
预期：每一期应玩家自动选择上阵的五个武将
根因：客户端梦境布阵入口 NightmareDeployData.sendSetTeam 发送 team_setteam，字段为 teamType=EMTeamType.nightMare=3、battleTeam、lordWeaponId，并在重新进入时通过 sendGetRoleTeam(..., EMTeamType.nightMare) 读取 roleTeam.battleTeamInfo[3] 和 nightmareTeam/nightmareWeaponId。服务端 TeamTypeMoonWar 错误占用了 3，导致梦境布阵保存到了 moonWarTeam/moonWarWeaponId，nightmareTeam 没有变化，客户端重新拉取仍看到旧的/默认 5 个武将，表现为无法更改选择武将。
修复：服务端队伍类型常量按客户端协议对齐：TeamTypeNightmare=3、TeamTypeMoonWar=9；team_setteam 对 teamType=3 写入并回包 nightmareTeam/nightmareWeaponId，同时同步 roleTeam.battleTeamInfo[3] 和 weapon[3]，不再污染月赛队伍。
验证：GOCACHE=/tmp/go-build-cache go test ./domains/social/team -run 'TestBuildFieldizedTeamPatch_NightmareUsesClientTeamType3|TestBuildSetTeamFieldizedResponse_NightmareDoesNotOverwriteMoonWar|TestBuildFieldizedTeamPatch_CargoRaid|TestBuildSetTeamFieldizedResponse_Success'；GOCACHE=/tmp/go-build-cache go test ./entry/social/teamentry。
截图：

问题5：
状态：已修复
现象：个人主页内 关闭不了切磋
预期：切磋可以正常关闭 关闭后别的玩家无法切磋挑战 开启后可以正常切磋
根因：客户端个人主页关闭切磋按钮调用 SystemService.setSwitch({typ: EMRoleSwitchType.pVP, value: !当前值})，实际协议为 system_setswitch，并依赖回包/角色信息里的 switches[1] 刷新按钮状态；服务端未注册 system_setswitch，角色模型也没有持久化 switches 字段，导致点击后状态无法保存和同步。
修复：服务端补齐 system_setswitch 协议注册、字段化保存 switches.<typ>，并按客户端读取口径返回 role/roleInfo.switches；新角色初始化空 switches，避免角色信息缺字段；fight_startpvp 读取目标玩家 switches[1]，关闭时拒绝发起切磋。
验证：GOCACHE=/tmp/go-build-cache go test ./entry/account/wsentry ./domains/account/login；GOCACHE=/tmp/go-build-cache go test . -run 'TestIsPVPChallengeOpen|TestPVPStatisticPhase|TestRegisterActivityAndSystemHandlers|TestBuildInitialRole'
截图：

问题6：
状态：已修复
现象：玩家被切磋挑战后 主页累计切磋次数不增加
预期：每被人切磋一次就增加一次
根因：客户端个人主页累计迎战切磋读取 ROLE.statistics["p:tc"]，昨日新增读取 ROLE.statistics["p:c:" + YYMMDD]；服务端 fight_startpvp 只生成并返回 battleData，没有在目标玩家（被切磋方）统计里递增 p:tc 和当天 p:c:YYMMDD，日志中多次 fight_startpvp 回包也只有 battleData，没有统计落库或同步痕迹。
修复：服务端在 fight_startpvp 成功生成战斗后，对被切磋方字段化递增 statistics.p:tc 和 statistics.p:c:<上海时区YYMMDD>，后续个人主页/他人主页读取角色信息时即可显示累计和昨日新增。
验证：GOCACHE=/tmp/go-build-cache go test . -run 'TestIsPVPChallengeOpen|TestPVPStatisticPhase|TestRegisterActivityAndSystemHandlers|TestBuildInitialRole'
截图：

问题7：
状态：已修复
现象：从个人主页 或者俱乐部排行榜查看俱乐部详情 俱乐部总战力和总红淬 俱乐部成员的名字 战力 红淬数量显示不对
预期: 俱乐部总战力和总红淬显示正确 俱乐部成员的名字 战力 红淬数量显示正确 根据成员目前上阵阵容实时刷新
根因：客户端俱乐部详情 LegionInfoDialog 读取 legionData.power、legionData.quenchNum，成员列表读取 member.power 和 member.custom["battle_red_quench_cnt"]；服务端 legion_getinfobyid 使用俱乐部表里缓存的 bang.Power/bang.RedQuenchCnt，成员 custom.red_quench_cnt/battle_red_quench_cnt/total_red_quench_cnt 又固定写 0，未按成员当前上阵阵容实时计算，所以截图中总战力/红淬和成员红淬都显示为 0。
修复：legion_getinfobyid 生成详情时按成员当前角色实时解析战力和上阵阵容红淬数，回填成员 custom 三个红淬字段，并用成员实时值汇总 legionData.power/quenchNum；读不到实时角色时才回退俱乐部缓存值。
验证：GOCACHE=/tmp/go-build-cache go test ./domains/legion/read -run 'TestBuildInfoByIDPayload|TestBuildInfoResponse'；全包 ./domains/legion/read 仍有既有 details_test.go 用例失败，和本次俱乐部详情字段修复无关。
截图：

问题8：
状态：已修复
现象：排行榜内没有俱乐部排行榜
预期：有俱乐部排行榜
根因：客户端排行榜 RankListDialog._fixTabs 创建俱乐部 tab 的完整条件是 IS_UNLOCKED(ModuleType.LEGION) 且 PlatformManager.checkSwitch(SwitchId.LEGION_RANK_SWITCH) 为 true；SwitchId.LEGION_RANK_SWITCH 在客户端配置里对应字符串 LegionRankSwitch，启动时会随 switch 批量请求发给服务端。服务端 switch_status_handler 的默认开启开关只包含 PaySwitch/CDNSwitch/ServerConfig 等，没有返回 LegionRankSwitch=1，所以客户端开关为 false，俱乐部排行榜 tab 没有被 push 到 tab 列表，后续 legion_getserverrank 协议也不会触发。
修复：服务端批量开关接口默认开启 LegionRankSwitch，按客户端请求顺序返回 1，保留原有 legion_getserverrank 数据协议不变。
验证：GOCACHE=/tmp/go-build-cache go test . -run TestHandleSwitchMultiStatus。
截图：

问题9：
状态：已修复
现象：点击充值内的首充礼包 界面会直接边空白 卡死 无法点击
预期：点击后正常出现首充礼包页面
根因：客户端福利活动页 ExcitingActivityDialog 点击首充活动后创建 ExcitingActivityFristChargeDialog，该页从 SERVER_DATA.activity.firstCharge.packId 读取首充包 id，再用 ChargePackConf.getById(packId) 填充奖励/价格，并设置 m_type.selectedPage = packId、m_isFirst.selectedPage = (packId === 1001)。服务端 activity_get1 的首充协议返回 packId=1001，但主活动面板 activity_get 硬编码返回 firstCharge.packId=1006，同一首充活动两条协议给出的包 id 不一致，导致福利页走到非首充 UI 控制器状态，出现空白卡住。
修复：activity_get 的 activity.firstCharge.packId 改为与首充协议一致的 1001，客户端继续按原字段读取，不改客户端。
验证：GOCACHE=/tmp/go-build-cache go test ./domains/activity/read -run 'TestBuildActivityResponseFromSnapshot|TestBuildLegacyActivityGet1Response'。
截图：

问题10：
状态：已修复
现象：灯神挑战和深海灯神内 武将伤害不对 两个满级武将不可能打不过第一关 满级司马懿伤害不可能那么低
预期：灯神挑战和深海灯神内 上阵武将伤害正常
根因：客户端 GenieModule 发起 FightService.startGenie({battleTeam, genieId, lordWeaponId}) 后，战斗表现完全依赖服务端 fight_startgenie 返回的 battleData.leftTeam.team。服务端 handler 已经注入 GetMergedBattleRole，用于拿带装备/淬炼/藏品/俱乐部等加成后的角色，但 buildGenieBattleDataWithResult 实际写成 battleRole := role，构造左队时直接使用原始角色裸属性，导致满级武将在灯神/深海灯神里攻击、血量等战斗属性偏低，截图中只能打出异常低伤害。
修复：灯神战斗构造 leftTeam 时优先使用 GetMergedBattleRole(roleId) 的合并加成角色；原始角色仍用于挑战次数、进度、奖励和阵容保存，避免把临时战斗加成对象写回存档。
验证：GOCACHE=/tmp/go-build-cache go test ./internal/geniex -run 'TestBuildGenieBattleDataWithResult_UsesMergedBattleRoleForLeftTeam|TestFightStart_ResponseIncludesSavedGeniePreset|TestReconcileGenieFallbackWin'。
截图：

问题11：
状态：已修复
现象：武将觉醒技能后 无损换将后以觉醒的技能就会被重置
预期：武将技能一但觉醒 不管怎么弄 永远都不会重置
根因：客户端无损换将只发送 hero_exchange，成功后依赖服务端同步 role.heroes[*].activeSkill/isActive/awakeSkill/skill 刷新觉醒状态。服务端 hero_exchange 在等级不一致分支会用 CreateHero + rebuildHeroExchangeSkills 重建被降级的一方，并对另一方重建技能列表；旧逻辑只保留图鉴、皮肤、HB 等英雄自身状态，没有保留 activeSkill/isActive/awakeSkill，同时技能列表回退为基础技能 ID，导致客户端觉醒页读到的字段变回未觉醒。
修复：无损换将重建英雄时保留 activeSkill/isActive/awakeSkill；重建技能列表后根据英雄配置的 awakeActive/awakePassive 把已觉醒主动和被动技能重新落回 activeSkill 与 skill。该状态按英雄自身保留，不随等级、装备等可交换成长资源转移。
验证：GOCACHE=/tmp/go-build-cache go test ./internal/gameplay/herox -run 'TestHandleExchange_PreservesAwakenedSkillState|TestHandleExchange_PreservesHeroSpecificState|TestHandleExchange_ResponseSkillsRemainCompleteAfterRebuild'。
截图：

问题12：
状态：已修复
现象：带有红淬且锁定的淬炼是 反面后变成了截图中的状态 点击也无反应 账号123456 密码123456
预期：翻面后正常五孔开启状态 并且可以洗练
根因：客户端 QuenchStageUpDialog 翻面后调用 EquipmentService.changeQuench({heroId, part})，随后立即用服务端同步的 equipment.curQuenchId、quenches、quenches2 刷新当前面。客户端展示逻辑固定读 equipInfo.quenches 作为当前页，服务端 maputil.StructToMap 已做了反面展示适配：当 curQuenchId 为反面时把反面数据换到 quenches。但 equipment_changequench 和 equipment_unlockquench2 在生成差异回包前先调用 UpdateRoleAfterChange，把当前快照提前更新，导致客户端可能拿不到翻面/反面解锁后的完整装备字段，只看到旧的/不完整淬炼状态，表现为反面槽位异常和点击无反应。
修复：调整 equipment_changequench、equipment_unlockquench2 的同步顺序，先 GetOptimizedRole 生成包含装备差异的回包，再 UpdateRoleAfterChange 更新服务端快照，确保客户端收到对齐后的 curQuenchId + quenches/quenches2/quenchTimes 字段。
验证：GOCACHE=/tmp/go-build-cache go test . -run 'TestInitUnlockedBackQuench_CreatesIndependentFiveSlots|TestBuildQuenchHistoryRecord_UsesCurrentBackSide|TestGetQuenchExt_UsesCurrentSide'；GOCACHE=/tmp/go-build-cache go test ./internal/maputil -run TestStructToMap_EquipmentBackSidePresentsCurrentQuenchFirst；GOCACHE=/tmp/go-build-cache go test ./internal/gameplay/equipmentx -run TestNormalizeRoleEquipmentQuenchSlots。
截图：

问题13：
状态：已修复
现象：珍宝阁内典藏套装 玩家未拥有武将对应皮肤和头像框背景 也显示点亮
预期：玩家拥有武将对应皮肤和头像框背景后 才会点亮 并且点亮数量达标后 会对该武将有额外加成
根因：客户端 CollectionThemeSuitsDialog/CollectionClosetSuitsDrawer 的点亮链路不是按本地配置猜状态，而是读服务端 collection.suitSeries[seriesId].collectMap 中每个资源的 activateNum/canActivateNum，以及套装星级的 claimProcess/colProcess。客户端配置里已有 CollectionHeroSuitsConf[10702]、CollectionHeroSuitsConf[11705]（典韦巨灵神套装包含皮肤 11705、头像框 111705、背景 7002），但服务端配置只包含 10403/11901，缺少客户端正在展示的套装，导致服务端无法按客户端套装项生成完整 suitSeries 状态，历史激活/领取进度也缺少按“是否真实拥有资源”的逐项压制。
修复：服务端 CollectionHeroSuitsConf 增加客户端已有但服务端配置缺失的 10702/11705 兜底套装定义，并复用现有拥有判断生成 collectMap。未拥有皮肤、头像框、背景时，服务端固定返回 canActivateNum=0、activateNum=0、claimActivateNum=0，且 claimProcess 会被实际已拥有且已激活进度钳制，避免旧 CollectionActivated 脏数据把未拥有项点亮。
验证：新增 TestBuildCollectionInfo_BuiltinHeroSuitRequiresOwnedItems，覆盖“只有典韦本体、没有巨灵神皮肤/头像框/背景，但数据库残留三项激活和领取进度”的场景，预期 11705 套装仍返回全暗。当前 go test . 在本地 main 包编译/初始化阶段 60 秒无输出超时，未拿到完整测试结果，需要部署环境或拆包后再跑完整回归。
截图:

问题14：
状态：已修复
现象:珍宝阁内激活鲁肃获取的藏品值不对
预期:别的武将都是25 鲁肃应该也25藏品值
根因：客户端珍宝阁不是固定写死鲁肃分数，而是读服务端 collection.heroSeries[121].collectMap[12101].activateScore。客户端配置 HeroConf[121].skinList 包含 12101/12104/12103/12105，且 SkinConf[12101].color=5，按 CollectionConf.heroSkinCollectionPoint[5] 应返回 25；服务端配置缺少鲁肃相关 SkinConf 行，collectionHeroSkinScore 找不到配置后走默认 1 分，导致鲁肃基础皮肤藏品值错误。
修复：服务端补齐鲁肃皮肤配置兜底，保证 12101 按 color 5 返回 25，12104 等鲁肃皮肤也按客户端同源配置计算分数。
验证：GOCACHE=/tmp/go-build-cache go test . -run 'TestBuildCollectionInfo_UnlocksConfiguredLuSu|TestBuildCollectionInfo_BuiltinHeroSuitRequiresOwnedItems'。
截图：

问题14：
状态：已修复
现象：玩家获取皮肤后 和领取藏品值奖励 不是实时刷新 需要退出再进才会刷新
预期：玩家获取皮肤后 珍宝阁会实时刷新 藏品值等级奖励领取后加成会立马到武将身上出现战力提升特效 不需要退出游戏在进入
根因：客户端 CollectionModule.onEnable 只监听 collection_changenotify，收到后才会主动调用 collection_getinfo 刷新珍宝阁；同时主页/战力变化走全局 syncresp.role.power。服务端获取皮肤、装扮、藏品激活/领取等回包只同步了局部 role 字段，缺少珍宝阁刷新通知，藏品激活后也没有稳定补最新 power，所以客户端必须退出重进或下一次完整拉角色后才看到刷新。
修复：服务端回包后统一检测 skinBook/lordSkin/dress/avatarFrame/customCard/airshipId/multiKillId/collectionActivated/collectionClaimScore/collectionSeriesClaim/collectionHeroSuitClaim 等珍宝阁依赖字段，变化时推送 collection_changenotify，让客户端按既有协议重新拉 collection_getinfo。collection_activate 和领取回包在清缓存后补最新 power 增量，保证主页战力链路有即时同步字段。
验证：GOCACHE=/tmp/go-build-cache go test . -run 'TestCollectionNotifyKeysChanged|TestBuildCollectionInfo_UnlocksConfiguredLuSu|TestBuildCollectionInfo_BuiltinHeroSuitRequiresOwnedItems'。
截图：

问题15：
状态：无需修复
现象：设置淬炼密码后 锁定多个淬炼时 每次第一次解锁不需要密码 解锁第二个才需要
预期：解锁成功后 5 分钟内免密，超过 5 分钟再次解锁才需要输入密码
结论：这不是服务端 bug。客户端 QuenchStageUpDialog 在解锁按钮前读取 ROLE.isNotNeedQuenchPassword，该值来自服务端同步的 statistics["que:wh:tm"]；服务端 passwordx.CommitPassword 校验密码成功后会写入当前时间 + 300 秒的免密截止时间，passwordx.CheckQuenchAccess 在 que:wh:tm 未过期时允许解锁。截图中的“不弹密码”符合 5 分钟免密规则。
验证：GOCACHE=/tmp/go-build-cache go test ./internal/gameplay/passwordx -run 'TestCheckQuenchAccess_RequiresPasswordWhenSetButNotCommitted|TestCheckQuenchAccess_AllowsWhenNoNeedWindowActive|TestCommitPassword_SetsNoNeedUntilFiveMinutesAndClearsErrors'；GOCACHE=/tmp/go-build-cache go test ./domains/growth/legacy -run 'TestHandleUpdateLock_UnlockRequiresAccessWhenConfigured|TestHandleUpdateLock_LockBypassesUnlockAccess'。
截图：

问题16：
状态：已修复
现象：账号密码123456 司马懿铠甲部位 正反面点击淬炼 词条不会变动 也不扣资源
预期：正常淬炼
根因：客户端点击洗练只调用 EquipmentService.quench，并按当前 curQuenchId 对应的 quenches 刷新词条；反面必须先通过 equipment_unlockquench2 成功初始化 quenches2，再由 equipment_changequench 切到反面。服务端旧链路存在反面解锁被密码校验拦截/反面未真正初始化的情况，后续 equipment_quench 只能看到未解锁或旧当前面状态，客户端表现为动画有了但词条不变、不扣资源。
修复：equipment_unlockquench2 按客户端协议只走金砖确认，不再返回客户端无法处理的淬炼密码错误；成功后初始化独立五孔 quenches2，服务端扣除 QuenchPunchCostDiamond 金砖并同步角色字段。正反面切换/洗练继续按 curQuenchId 写入并返回当前面 quenches。
验证：GOCACHE=/tmp/go-build-cache go test . -run 'TestInitUnlockedBackQuench_CreatesIndependentFiveSlots|TestQuenchPunchCostDiamond_UsesConfigFallback|TestBuildQuenchHistoryRecord_UsesCurrentBackSide|TestGetQuenchExt_UsesCurrentSide'。
截图：

问题17
状态：已修复
现像：点击翻面提示开启成功 一直重复 无法真正翻面 账号 0000 密码123456
预期：正常翻面 开启反面淬炼
根因：客户端翻面解锁弹窗确认后调用 equipment_unlockquench2，该协议没有密码输入分支，只会根据 e.code 判断成功/失败；服务端却先执行 passwordx.CheckQuenchAccess，日志中 equipment_unlockquench2 返回 code:9 msg:需要淬炼密码，随后客户端又发 equipment_changequench，服务端因为 quenches2 没有初始化返回 code:5 msg:反面装备洗练未解锁。所以页面会反复停留在“解锁第二套淬炼”的确认链路。
修复：equipment_unlockquench2 移除淬炼密码拦截，改为服务端校验并扣除客户端配置 QuenchPunchCostDiamond 金砖；成功后初始化反面五孔并返回同步角色数据，之后 equipment_changequench 可以正常切换正反面。
验证：GOCACHE=/tmp/go-build-cache go test . -run 'TestInitUnlockedBackQuench_CreatesIndependentFiveSlots|TestQuenchPunchCostDiamond_UsesConfigFallback|TestBuildQuenchHistoryRecord_UsesCurrentBackSide|TestGetQuenchExt_UsesCurrentSide'。
截图：

问题17:
状态：已修复
现象：赠送功法显示上限 显示以赠送22023次
预期：根据vip等级高低 和特权等级 有相应的功法赠送次数
根因：客户端功法赠送页 LegacyMailDialog._refreshUI 直接读取 SERVER_DATA.roleLegacy.sendLegacyCnt 展示“已赠送功法数”，上限由 LegacyGiftConf 的 VIP/特权配置计算。服务端 legacy_create 创建功法时错误复用了 RoleLegacy.SendLegacyCnt 作为“创建/洗功法任务进度”，每创建一次功法都会累加到赠送计数，历史账号因此出现 22023/3 这种被创建次数污染的赠送上限显示。
修复：legacy_create 只更新任务进度 task[2/3/4]，不再写 sendLegacyCnt，回包也不再同步赠送计数字段；legacy_getinfo、赠送和领取链路按 sendGiftResetTime 做每日计数归零，赠送/领取成功后按客户端读取字段同步 sendItemCnt/sendLegacyCnt/receivedItemCnt/receivedLegacyCnt/sendGiftResetTime。
验证：GOCACHE=/tmp/go-build-cache go test ./domains/growth/legacy -run 'TestHandleCreate_ReturnsCreatedUIds|TestNormalizeGiftDailyCounts'。
截图：