问题反馈2026.5.31 ¶

问题1：
状态：部分修复，Android 个人头像验收通过；俱乐部头像清缓存回退已修复待验收；iOS 已出包待真机验收
现象：游戏内头像和俱乐部头像不可以自主更换
预期：游戏内头像和俱乐部头像可以正常自主更改
截图：

修复记录：客户端个人头像确认后调用 RoleService.changeHeadImg，协议为 role_changeheadimg；俱乐部头像刷新调用 LegionService.syncLogo，协议为 legion_synclogo。服务端未注册这两个协议，导致选图/确认后无法写入角色头像或俱乐部 logo。已补齐 role_changeheadimg、system_updateheadimg、legion_synclogo 服务端处理：个人头像写入 role.headImg 并同步 role/roleInfo，团长同步俱乐部头像时写入 legion.logo、custom.leader:logo 和团长成员头像，并返回客户端期望的 rawData.info。验证命令：env GOCACHE=/tmp/xianyu-go-build go test -count=1 ./domains/core/appearance ./entry/account/wsentry。

补充进展（2026-06-02）：二次验收发现服务端协议已通，但 Android 客户端仍卡在原生选图入口。客户端日志显示点击换头像后 file.chooseImage 直接 Promise.reject(null)，随后业务代码读取 null.imagePath 抛 Cannot read property 'imagePath' of null；未进入 role_changeheadimg。根因是当前 Cocos Native Android 包 PLATFORM=android 走 PlatformNative -> PlatformMix.chooseImage -> platform.file.chooseImage，但 platform.file.chooseImage 只放行 Egret Native/MixMicroEnd/微信/QQ/抖音等平台，没有把 Cocos Native Android 识别为支持选图；同时 Android 原生工程只有 Cocos 默认 Activity 和 GameShield，没有相册选择桥接。已修复 Android：在 AppActivity.java 增加 chooseImage(callbackId)，用系统相册 ACTION_GET_CONTENT image/* 选图，复制到 app cache 后回调 JS {imagePath, images:[path,path]}；在 platform-native.js 中 Android native 覆写 chooseImage，通过 jsb.reflection.callStaticMethod 调 Java；NewChangeHeadImgDialog 增加空返回兜底。重新编译并安装测试包后，个人头像链路已成功，服务端日志：cmd=role_changeheadimg respCmd=syncresp roleId=151830 account=fafa response={"code":0,"keys":["code","role","roleInfo"]} sendOk=true trace_id=151830-fafa-44-role_changeheadimg。Mongo 验证 fafa/151830 是俱乐部 151830 团长，且 legion.logo、custom.leader:logo 已等于当前 role.headImg：http://xycdn.dbjdds.com/avatars/151830/1780371342-de764a21800ec5e2.jpg。俱乐部同步协议入口仍为 legion_synclogo，会把团长当前 headImg 同步到俱乐部 logo；本次本地日志未捕获新的 legion_synclogo 请求，因为数据已处于同步后状态，后续若再点刷新应查 cmd=legion_synclogo、response.code=0。

俱乐部头像二次修复（2026-06-02）：用户复现“同步后客户端清理缓存又变回去”。测试服日志显示 18:31:31 cmd=legion_synclogo roleId=151830 account=fafa response.code=0 成功，18:32:29 后客户端重新发 cmd=legion_getinfo 拉俱乐部详情。根因是服务端写路径 legion_synclogo 已把头像保存到 legion.logo，但清缓存/重登后的读路径 BuildInfoResponse 给 legion_getinforesp.info.logo 硬编码返回空字符串，客户端俱乐部面板读取的正是 info.logo，所以在线同步时看起来成功，重新拉详情后回退。已修复 server/domains/legion/read/info.go：info.logo 改为返回 bang.Logo，并补充回归测试覆盖已保存 logo。验证：先跑红灯 TestBuildInfoResponse_UsesStoredLegionFields 失败为 expected stored logo, got，修复后 env GOCACHE=/tmp/xianyu-go-build go test -count=1 ./domains/legion/read 和 env GOCACHE=/tmp/xianyu-go-build go test -count=1 ./entry/account/wsentry 通过；已部署测试服，/api/ready 返回 Mongo/Redis true。客户端无需修改，待再次清缓存实机验收。

iOS 修复进展（2026-06-02）：iOS 同样走 PLATFORM=ios -> PlatformNative，此前 platform-native.js 只放行 isAndroidAndNative，导致 iOS 退回 base chooseImage 并返回失败。已修复 JS 平台分支为 Android/iOS native 都走原生选图，iOS 通过 jsb.reflection.callStaticMethod("AppController", "chooseImage:", callbackId) 调 ObjC。远端 Mac iOS 工程 proj.ios_mac/ios/AppController.mm 已增加 UIImagePickerController 选图桥接，选中后写入临时 jpg 并回调 {imagePath, images:[path,path]}；Info.plist 已补 NSPhotoLibraryUsageDescription=用于选择图片作为头像。19:18 曾用全量 Cocos 重构建包 /var/www/web-mobile/xianyu-test-com.ming.0203-chooseimage-personal-signed-20260602-191812.ipa，实机反馈黑屏；为避免资源/构建产物差异，20:01 改为以首个可启动包 xianyu-test-com.ming.0203-personal-signed-20260602-185415.ipa 为底包，保留其 assets/game/index.640c9.js、assets/main/index.68196.js、图标和资源，只替换带 iOS 桥接的原生 client-mobile、Info.plist，并在 index.68196.js 内做最小 chooseImage 分支补丁后重签。验证：远端 codesign -vvv --deep --strict 通过，包内 index.68196.js 包含 AppController chooseImage: 和 isAndroidAndIOSAndNative，Info.plist 包含 com.ming.0203 与 NSPhotoLibraryUsageDescription=用于选择图片作为头像，本机 unzip -t 无压缩错误，origin 强制解析访问安装页/plist/latest IPA 均为 200。已发布个人签名 IPA：/var/www/web-mobile/xianyu-test-com.ming.0203-chooseimage-minpatch-personal-signed-20260602-200144.ipa，latest 指向 xianyu-ios-test-latest.ipa；安装页为 https://xy3.dbjdds.com/install-ios.html。注意：该个人描述文件只包含 UDID 00008140-001151861E30801C。

iOS 选图闪退补充（2026-06-02）：20:01 最小补丁包实机反馈“游戏内改头像，选择完图片后闪退”。定位 iOS 原生桥接有两个问题：didFinishPickingMediaWithInfo 直接对相册原图执行 UIImageJPEGRepresentation(image, 0.92)，大图会造成内存尖峰；同时 xianyuCompleteChooseImageWithPath 在 UIKit dismiss completion 中直接 se::ScriptEngine::getInstance()->evalString，没有像 Android Cocos2dxHelper.runOnGLThread 一样切回 Cocos 线程。已修复 AppController.mm：选中图片先按最长边 1024 缩放并以 0.82 质量写入临时 jpg，降低内存峰值；JS 回调改为 cocos2d::Application::getInstance()->getScheduler()->performFunctionInCocosThread 后再 evalString；补充原生日志 xianyu chooseImage selected 和 xianyu chooseImage callback。验证：Xcode Release 原生编译 ** BUILD SUCCEEDED **，远端 codesign -vvv --deep --strict 通过；新包仍以 18:54 可启动资源为底包，包内资源为 assets/game/index.640c9.js、assets/main/index.68196.js，本机 unzip -t 无压缩错误，origin 安装页/plist/latest IPA 均为 200。已发布 crashfix 包：/var/www/web-mobile/xianyu-test-com.ming.0203-chooseimage-crashfix-personal-signed-20260602-203835.ipa，latest 已指向该包。

iOS 闪退日志复盘（2026-06-02）：用户提供 /root/client-mobile-2026-06-02-205839.ips，崩溃不是 OOM/Jetsam，而是 EXC_BAD_ACCESS / SIGSEGV，faultingThread=0，栈顶为 objc_msgSend -> -[AppController xianyuCompleteChooseImageWithPath:error:]，selector 为 stringByReplacingOccurrencesOfString:withString:。根因是 iOS 工程未启用 ARC，xianyuCompleteChooseImageWithPath 里 NSString *callbackId = self.xianyuChooseImageCallbackId; self.xianyuChooseImageCallbackId = nil; 会释放 property 持有的 callbackId，随后继续对野指针做 JS 字符串转义；同时 dismiss completion 里延迟使用的 path/error 也需要显式持有。已修复为 callbackId = [self.xianyuChooseImageCallbackId copy]，使用后 [callbackId release]；dismiss completion 前对 resultPath/resultError 做 copy，completion 内回调后 release。验证：Xcode Release 原生编译 ** BUILD SUCCEEDED **，远端 codesign -vvv --deep --strict 通过，包内资源仍为 18:54 可启动底包 assets/game/index.640c9.js 与 assets/main/index.68196.js，本机 unzip -t 无压缩错误，origin 安装页/plist/latest IPA 均为 200。已发布 retainfix 包：/var/www/web-mobile/xianyu-test-com.ming.0203-chooseimage-retainfix-personal-signed-20260602-210802.ipa，latest 已指向该包。

iOS 头像成功但不显示复盘（2026-06-02）：retainfix 包实机不再闪退，客户端提示“修改头像成功”，但头像未显示；客户端日志显示 loadAsset:Error: Bundle icons doesn't contain data:image/jpeg;base64,...。根因是服务端 role_changeheadimg 回包和 syncresp 正确把 role.headImg/roleInfo.headImg 更新为 data:image/jpeg;base64,...，但客户端通用头像显示函数 UIHelper.setHeadIcon/setHeadImg 仍无条件调用 GLoader.load(headImg, BundleName.ICON, ...)，把 base64 data-url 当作 icons bundle 资源名加载，导致显示失败。已修复客户端显示层：UIHelper.setHeadIcon 和 setHeadImg 遇到 data:image/ 直接走现有 ImageUtil.setBase64Img，普通资源路径仍清理 base64 overlay 后走原 bundle 加载。验证：displayfix IPA 包内 assets/game/index.640c9.js 已包含 data:image/、setBase64Img、clearBase64Img 分支，assets/main/index.68196.js 仍包含 iOS AppController chooseImage: 分支；本机 unzip -t 无压缩错误，远端 codesign -vvv --deep --strict 通过，origin 安装页/plist/latest IPA 均为 200。已发布 displayfix 包：/var/www/web-mobile/xianyu-test-com.ming.0203-chooseimage-displayfix-personal-signed-20260602-220730.ipa，latest 已指向该包。

问题2：
状态：验收通过
现象：切换皮肤后 当前武将战力会下降 面板数值会变化（应该是哪里的加成掉了）退出游戏再进后会恢复
预期：更换皮肤不影响战力和武将面板数值 （截图一为更换前 截图2为更换后）
截图1：
截图2：

修复记录：二次定位根因为服务端在线增量战力/面板重算视图漏读 petData。hero_useskin 成功后走 LoadRoleViewForBonusWithBattleTeam 构造最小 Role 视图，该视图原本只读英雄、神器、阵容等字段，没有读取宠物数据，导致 equippedPetHeroBonus 在在线重算时拿不到已上阵宠物和精炼词条加成；退出重进走全量 Getrole 读取完整 petData，所以面板恢复。已修复最小视图加载 petData，并保留 hero_useskin_diag 输出 heroPanel 方便验收复现。验证命令：env GOCACHE=/tmp/xianyu-go-build go test -count=1 ./internal/bonusviewx ./internal/gameplay/herox。

问题3：
状态：验收通过
现象：如截图 原本武将攻击为12.25亿 下掉鱼灵后为9.38亿 在佩戴上攻击力却是11.64亿 佩戴前后攻击力不血量战力等一致 （应该是卸载鱼灵导致某个地方加成不生效） 退出游戏再进后会恢复
预期：同样加成属性的鱼灵 卸载佩戴后战力 攻击力血量等应该还是恢复原本的状态
截图：

修复记录：二次定位根因为服务端鱼灵卸下/佩戴后的在线增量重算视图漏读 petData。artifact_unload/artifact_load 回包会携带重算后的英雄面板，但重算依赖的 LoadRoleViewForBonusWithBattleTeam 没有加载宠物数据，导致宠物上阵与精炼词条加成在线态丢失或不完整；退出重进走全量角色读取后恢复。已修复最小视图加载 petData，同时 artifact_load 回包统一为 syncresp + code + role + roleInfo，并增加 artifact 诊断日志输出 heroPanel。验证命令：env GOCACHE=/tmp/xianyu-go-build go test -count=1 ./internal/bonusviewx 和 env GOCACHE=/tmp/xianyu-go-build go test -count=1 . -run TestBuildArtifactLoadResp。

问题4：
账号：fafa1 时间：2026.5.31 23:08
状态：待验收 验收通过
现象：待精炼词条的上阵会复制现在上阵宠物的词条 退出游戏再进后会恢复
预期：没精炼词条的上阵后依然没词条不会复制 每个宠物都需要单独去精炼
修复说明：二次定位确认数据库中的宠物 uId/词条本身没有复制，fafa1 复现时日志与 Mongo 均显示未精炼宠物 quenchCount=0。症状会退出重进恢复，根因为在线宠物上阵/面板刷新链路使用的最小 Role 视图漏读 petData，导致当前上阵宠物词条加成在线态与面板重算不同步，看起来像词条串到新上阵宠物。已修复最小视图加载 petData，并保留 pet_load_diag 输出 source/equipped quenchCount 和 duplicateUidCount；此前 pet_load 历史重复槽清理逻辑继续保留。验证命令：env GOCACHE=/tmp/xianyu-go-build go test -count=1 ./internal/bonusviewx ./domains/pet。
截图:

问题5：
账号：fafa1 时间：2026.5.31 16:15
状态：待验收 验收通过
现象：宠物精炼词条不生效 加成不到面板 （截图1为精炼前 截图2为精炼后）
预期：所有词条加成都正常生效 面板有的 凸显在面板上
修复说明：已定位为宠物精炼 5/6/7/8 基础百分比词条只进入特殊 attribute map，未并入武将基础面板读取的 calculateAttack/calculateHp/calculateDefense/calculateSpeed。已修复权威面板/战力公式，基础百分比现在直接作用到战斗队伍武将基础属性，待验收。
截图1：

截图2：

问题6：
账号：fafa1 时间：2026.5.31 16:15
状态：待验收 验收通过
现象：宠物精炼词条不足 很多词条没有（下方截图是所有词条属性）
修复说明：已定位为服务端宠物精炼随机池缺少客户端 petSpecialBattleAttribute 支持的多项词条。已补齐随机池并补充配置完整性测试，待验收。
预期：所有词条都有

问题7：
状态：已修复 验收通过
现象：武将典韦，张角基础速度不对 现在典韦满级速度是2650 每升一级加0.44 张角是3130 每升一级加0.52
预期：典韦6000级速度为2437 每升一级加0.40 张角6000级速度为2782 每升一级加0.46
截图：

问题8：
状态：已修复，待验证
现象：十殿挑战内 每过一关就扣除一个睡梦枕头 例如：打到第八关结束 就扣除八个
预期：每次挑战只扣除本次挑战队长队员每人各一个枕头 不论关卡
美梦枕头（挑战消耗道具）
每周一 0 点刷新 6 个枕头，不可留存到下周
消耗规则：
当日前 3 次挑战：1 枕头 / 次；当日第 4 次起：2 枕头 / 次
开队伍仅队长扣枕头，全员准备开战才正式消耗道具，退队不返还
截图：

修复记录（2026-06-01）：服务端根因是 nightmare_fight 按关卡触发消耗，且 nightmare_getroleinfo 固定返回 todayFightCnt=0，未实现 5054 美梦枕头周一 0 点刷新与日挑战次数。已改为房间首次正式开战才消耗一次；每周一 0 点重置 5054 为 6，不留存；按今日次数计算前 3 次 1 个、第 4 次起 2 个；getroleinfo 返回真实 todayFightCnt/tFResetTime。已通过 targeted go test、go build、APK 包内配置校验，待测试服部署后实机复测。

问题9：
状态：已修复，验收通过
现象：宠物精炼词条有破甲和破甲抵抗
预期：宠物精炼词条内没有破甲和破甲抵抗
截图：

修复记录（2026-06-02）：已按问题描述、截图、客户端源码、服务端源码和本机日志完成定位。截图中精炼结果出现“破甲/破甲抵抗”，但规则说明截图的宠物精炼可随机词条列表没有这两项；客户端 PetModule.sendQuench 调 PetService.quench，界面 PetInfoQuenchDrawer/PetQuenchCheckDialog 直接展示服务端返回的 quench.attrs[].attrId，所以显示“破甲/破甲抵抗”不是客户端本地随机。服务端根因是历史补齐宠物精炼词条池时，在 server/config/pet_prob.json 的 quenchAttrs 中加入了 51=破甲、52=破甲抵抗，pet_quench 经 petprob.RollQuenchAttrIDs 抽池时会随机产出这两个不允许的属性。本机日志 server/logs/2026-06-01/app-000000-000000.log、server/logs/2026-06-02/app.log 和 client_track 中未检索到对应 pet_quench 请求记录，因此本次以配置/代码路径和截图作为确定性证据。已从 server/config/pet_prob.json 移除 51/52，并增加回归测试防止再次进入宠物精炼随机池；验证命令：env GOCACHE=/tmp/xianyu-go-build go test -count=1 ./internal/gameplay/petprob ./domains/pet。

问题10：
账号：fafa1 时间：2026 6.2 1:10-1:12
状态：已修复，验收通过
现象：拥有三件套的5个武将(大乔 吕布 周瑜 诸葛亮 典韦) 激活三件套后 点击跟换皮肤会降战力
预期：激活三件套后加成锁死武将 更换皮肤不影响加成
截图：

修复记录（2026-06-02）：已按问题描述、截图、客户端源码、服务端源码和本机日志完成定位。截图中吕布换肤后面板战力从 47673 变为 46959，表现为换肤触发的在线面板重算丢失一部分外部加成；客户端换肤入口 HeroTrainDialog 调 HeroService.useSkin({heroId, skinId})，协议为 hero_useskin。服务端 HeroUseSkinFieldized 保存 heroes.<id>.useSkin 后，会调用 LoadRoleViewForBonus 取最小 Role 视图并用 GetMergedHeroResponse 重算英雄面板、推 syncresp。根因是该最小视图只加载 lord/军团/宠物/鱼珠/英雄等字段，没有加载珍宝阁三件套加成依赖的 collectionActivated、collectionHeroSuitClaim、avatarFrame、dress；collectionClaimedSuitBonuses 因字段为空算不出已领取三件套加成，导致换肤后的在线面板战力下降。已在 LoadRoleViewForBonusWithBattleTeam 补齐这些字段加载，保证换肤、上下阵等在线重算与全量登录视图使用同一套三件套加成数据。本机日志 server/logs/2026-06-01/app-000000-000000.log、server/logs/2026-06-02/app.log 和 client_track 未检索到该时间窗口的 hero_useskin 请求记录，因此本次以截图、客户端请求路径、服务端重算路径和回归测试作为确定性证据。验证命令：env GOCACHE=/tmp/xianyu-go-build go test -count=1 ./internal/bonusviewx ./internal/gameplay/herox . -run 'TestLoadRoleViewForBonusWithBattleTeam|TestHeroUseSkin|TestCalculateHeroBonus_AppliesClaimedCollectionSuitBonus|TestCollectionClaimedSuitBonuses_AppliesClaimedHeroSuitStages'。

问题11：
状态：已修复，奖励显示已验证；领取待验证
现象：通行证内爬塔之路奖励显示为空
预期：正常显示奖励 并且达到要求可以正常领取
截图：

修复记录（2026-06-02）：已按问题描述、截图、客户端源码、服务端源码和服务端日志完成定位。截图对应限时活动-通行证-爬塔之路页签，奖励格为空；客户端点击页签后会请求 evotower_getinfo 和 activity_get，EvoTowerBattlePassDialog 固定使用 activityId=1003，基础通行证界面依赖 SERVER_DATA.activity.warOrderActivityInfo.get(1003) 才继续刷新奖励列表。服务端日志显示 fafa/151830 的 evotower_getinfo 与 activity_get 都返回成功：trace_id=151830-fafa-79-evotower_getinfo、trace_id=151830-fafa-80-activity_get，但日志只证明外层响应成功，不能证明 activity.warOrderActivityInfo.1003 存在。服务端根因是 activity_get 读路径 BuildActivityResponse -> buildWarOrderActivityInfo -> NormalizeWarOrderActivityInfo 只给默认战令 1 补空状态，没有给爬塔之路战令 1003 补默认状态；新号或未触发过领取/购买写入的账号会缺少 warOrderActivityInfo["1003"]，客户端因此不进入通行证刷新链路，最终奖励格显示为空。已在 server/domains/activity/battlepass/recycle.go 中统一补齐默认战令活动 1/1003/1004 的空状态，保证 activity_get 下发 warOrderActivityInfo.1003。验证命令：env GOCACHE=/tmp/xianyu-go-build go test -count=1 ./domains/activity/battlepass -run 'TestNormalizeWarOrderActivityInfo|TestClaimRecycleWarOrder'、env GOCACHE=/tmp/xianyu-go-build go test -count=1 ./domains/activity/read -run 'TestBuildActivityResponseFromSnapshot_NormalizesWarOrderActivityInfo'。实机复测结果：2026-06-02 你确认爬塔之路奖励已经可以显示；领取链路仍需达到条件后再看 activitybattlepass_claim/相关领取协议日志闭环。

问题12
状态:已修复，验收通过
现象:挑战深海灯神和普通灯神时 宠物上阵不显示宠物 且深海灯神10赢了判定输
预期:正常显示上阵宠物 赢了不会判定输
截图:

问题13：
状态：未处理
现象：灯神挑战挑战后显示的战力不是当前阵容战力 而是外部主线战力
预期:布阵上场的阵容战力是多少战斗时显示的战力就是多少
截图：

修复记录（2026-06-02）：已按问题描述、截图、客户端源码、服务端源码和本机日志完成定位。截图对应灯神挑战战斗，普通灯神战斗左侧宠物位显示“无”，深海灯神 10 战斗中极限回合下判输。客户端入口 GenieModule.sendStartGenie 调 FightService.startGenie({battleTeam, genieId, lordWeaponId, petUId})，GenieDeployDataAdapter 从 ROLE.geniePet[club] 或当前选择宠物读取 petUId，说明客户端会把宠物选择传给服务端。服务端根因是 server/internal/geniex/startfight.go 的 FightStartRequest 没有声明 petUId，fight_startgenie 解析请求时直接丢弃客户端宠物参数；同时 buildGenieLeftTeam 没有调用 rolepetx.DecorateTeamWithPet，导致下发给战斗服和客户端战斗 UI 的 battleData.leftTeam 缺少 pet/petUId/petActiveSkillId，普通/深海灯神都会显示未上阵宠物，深海 10 也会按缺宠物属性/技能的输入参与胜负计算。对比其它玩法，竞技场、梦魇、Boss 塔等服务端战斗构造都会调用 DecorateTeamWithPet 或 buildLeftTeamWithPet，只有灯神漏了该链路。本机日志 server/logs/2026-06-01、server/logs/2026-06-02、server/runtime/logs 未检索到截图战斗 ID 或对应 fight_startgenie 请求，因此本次不是通过日志直接发现根因，而是通过客户端协议字段、服务端请求结构和战斗数据构造链路确定。

修复方式：FightStartRequest 增加 PetUId；models.Role 增加 GeniePet 并补齐 deep copy、RoleDiff 保存检测；灯神开始战斗时优先使用请求 petUId，其次使用已有 geniePet[club]，最后回退当前上阵宠物；保存灯神预设时同步保存 geniePet[club]；构造 battleData.leftTeam 时调用 rolepetx.DecorateTeamWithPet，确保战斗输入和客户端战斗 UI 都有宠物摘要和宠物技能。已增加回归测试覆盖“请求带 petUId 时战斗数据和响应带宠物”以及“空 petUId 时默认回填当前上阵宠物”。验证命令：env GOCACHE=/tmp/xianyu-go-build go test -count=1 ./internal/geniex、env GOCACHE=/tmp/xianyu-go-build go test -count=1 . -run 'TestFightStartGenie|TestDebugGenieBattleRole611284|TestNormalizeGenieBattleStatsForClient'、env GOCACHE=/tmp/xianyu-go-build go test -count=1 ./internal/deepcopy ./internal/roleopt。已执行 deploy/bin/update.sh test 更新本机测试服 Docker，/api/ready 返回 {"checks":{"mongodb":true,"redis":true},"status":"ready"}，/api/health 返回 OK，battle-worker stats 返回正常；待实机重新打普通灯神和深海灯神 10，复查 fight_startgenie 日志中 battleData.leftTeam.petUId/战斗显示/胜负结果闭环。