8.1 KiB
最小真实玩法闭环：范围与接线核查
最新状态：用户已确认单账号重启式重登；本核查已收敛为《阶段4最小真实玩法闭环方案-待评审-2026-09-24.md》。以下保留设计准备过程；当前完整R1方案待独立审查，尚未批准新生产改动。 用户已明确选择真实游戏内的一条普通玩法闭环，而非再增加独立验证面板。此文件记录源码事实与收敛方向，不冒充已完成方案评审。
目标与代表操作
首选：正常游戏登录→进入已有鱼竿面板→装备另一根已拥有且未锁定的鱼竿→通过KV保存→退出后重新启动游戏登录→装备状态从服务器恢复。使用专用可丢弃测试账号，验收前需明确账号、已有数据备份和允许写入范围；原101/102专用fixture授权不自动覆盖全量业务存档。
不在首轮改变升级、抽奖、付费、扣体力或奖励算法；不做外围迁移、SDK删除、通用回调框架或数据格式重构。现有安全底层和31模块codec继续复用。该闭环不等于正式玩法/G4全部放行，也不能绕过P2-α真实存量档启用门。
已核对的真实调用链
| 接入点 | 源码事实 | 对最小方案的约束 |
|---|---|---|
| UI/Rod/FishingRodPanel_Level.cs OnClickEquip | 调用SetEquipRodID后更新UI与成功提示 | 先捕获本次归属；失败不能继续显示保存成功 |
| DataCenter/DataCenter.PlayerData.cs SetEquipRodID | 修改equipRodID、更新红点、调用SavePlayerData | 不能只在最后HTTP请求处判断失效；首轮尽量保留业务顺序和算法 |
| 同文件SavePlayerData | 先发布PlayerData事件；组装19核心字段及vipL/ld/ad/bd/ct/rt；保存整个NewPlayerDataDic | 并非写独立EquipRodID key，需要完整加载关联状态，不能用默认其他字段覆盖 |
| Core/PlayFabMgr.cs | 旧读写和40秒同步仍走PF/PlayerPrefs；新四入口尚无业务调用者 | 应评估在既有facade统一路由，避免逐个重写81个调用文件；不得PF/KV双写或加载拼接两份档 |
| Services/UserService.cs LoginCore | 仍先PF登录/初始化，再API登录，最后Done | 需要真正调整KV模式加载顺序，不能设置SaveBackend=kv就宣称接通 |
| Services/UserService.KVLoad.cs | 明确拒绝kv；受控对象及验证接收者和正常对象不同 | 验证接口不能直接改名当生产入口；需要最小运行时发布合同 |
| PlayerKVGameLoadCoordinator | LoadedForValidation要求guard持续有效；只开放受控加载 | 释放guard、发布写权限、退出排水必须一起设计，不能只加一个Dispose |
| PlayerKVControlledLoadCapability | 目前工厂只提供Editor合成传输 | 真实会话绑定需明确复用同一次认证Cookie；不得复用合成工厂偷换真实handler |
| PlayerKVEditorValidationHost | 31模块组合在独立容器中构造 | 正常游戏应绑定真实容器既有对象，不再创建平行业务对象或复制31模块算法 |
| UserService.GetPlayLv | PF读取目标玩家Lv | 不能机械改为本人KV；外围身份暂时保留明确分工 |
三条路线与当前建议
| 路线 | 改动与效果 | 判断 |
|---|---|---|
| 先按原B/C覆盖全部回调、换号及生命周期 | 完整但首次可运行较晚，业务改动面大 | 不作为默认先行路线 |
| 真实游戏单账号首轮闭环，复用统一facade和完整加载；会话结束后需重启游戏再登录 | 可在一次运行中固定原handle；有机会避免首轮逐业务改写跨账号回调，仍须真实加载/存储失败处理 | 用户已接受首轮单账号、重启式重登；按此约束收敛完整接入方案 |
| 新独立验证入口 | 改动最少但不是用户选择的真实游戏闭环 | 不替代目标 |
单账号限制若采用，必须是代码硬约束：本进程曾发布游戏会话后不再发布第二个账号/epoch，撤销后保持关闭；不能只靠“测试时不换号”。Unity停止Play再进入不必然销毁静态状态，必须明确域重载条件；不能把销毁Root或手动清静态变量冒充彻底重启。用户已确认此产品限制；技术实现仍需纳入完整接入评审。
完整方案必须闭合的三处，合并到一次接入评审
- 启动与加载：定位真实Root/配置/PlayFabMgr.Awake顺序，明确在任何PF存档初始化及自动写之前固定后端；将已有31模块Decode/Reset/Replace绑定真实对象，列清配置快照、账号资料与启动后自动副作用。失败不Done、不写默认档，不引入第二套加载器。
- 发布与保存：明确同一Context/handle的准备→加载→可写→撤销顺序；原有facade签名尽量保留，错误不得伪装为缺档/成功。Equip实际保存整个NewPlayerDataDic，须验证同一次序列化的关联模块字段及事件副作用。普通同步、暂停、退出复用原Owner，不能出现两个定时器或偷偷改用当前账号。
- 真实运行边界：落实已获用户确认的单账号重启式重登；测试账号及数据准备/备份/恢复；菜单可达消费和后台回调是否影响该闭环；精确文件白名单及实测验收。不能通过只写一个key却打开全游戏来掩盖其他保存来源。
待这些点落实后，产出一份合并的最小接入方案与提示词，统一审查原B/C首次范围调整和必要生产改动；不再为每个小接口单独新增阶段。当前候选涉及UserService/KVLoad、既有Context/Coordinator、PlayFabMgr、启动/退出接线和鱼竿装备入口；候选不是修改授权清单。
最小验收结果
- 真实游戏使用专用账号完成上述装备操作，保留原始游戏界面和业务序列化。
- 网络证据确认本账号KV加载与Set，存档路径无PF回退/双写；Accepted和远端Confirmed分别记录。
- 完成Flush后重启，使用新的隔离缓存根读取服务器并恢复装备值；不以同一内存或旧缓存充当重登证据。
- Get/解析/存储/发送失败明确停止该流程；没有空档覆盖、跨账号写或错误成功提示。
- 只运行针对接线变更的必要回归；不因文档更新重跑已通过的全套验证。
正式地址固定http://s101.local:18080/；Unity CLI Loop、不用UnitySkills、暂不打包。进入PlayMode和真实业务写应在接入方案审查及测试数据边界明确后执行；本轮只读核查，没有启动游戏或访问正式服务。
设计检查点1：用户确认限制与启动接线事实
用户已接受单账号运行、重启游戏后重登恢复，游戏内重登/换号留后续。无需重复索取该偏好。
进一步核查：SubBoostrap.RegisterServices在第88行AddComponent，会立刻Awake并开启旧40秒循环；RootCtx已注册IConfig，Boostrap在资源加载后调用RegisterServices再调用AfterAssetUpdate。必须在AddComponent之前锁定本次模式，不能等LoginCore后再阻止旧存档初始化。LoginStage随后注册真实IUserService/业务对象；PFLoginAct或AggLoginAct完成后转入FishingStage，FishingStage.InitData还会调用多模块Init并发布登录事件，这些可能触发普通保存，不能只测装备按钮。
发现可缩小的路线：正常UserService已拥有apiSession，CustomServerMgr已用UseAccountSession绑定同Cookie。可优先评估让该服务直接持有已验收的4A Bridge，复用4B2 Schema/Transaction，避免为了接真实网络去改造B2仅验证用的Capability/Context/Coordinator。该复用需明确构造准备结果所依据的真实认证与快照事实、31模块真实对象绑定、发布顺序和退出先排水后Dispose；不是伪造Prepared结果或新增第二个认证会话。此路线可减少对已关闭底层的改动，但尚未完成方法级设计与评审。
现有Logout会直接Dispose apiSession，401还可能自动LoginApiServer；最小模式须在这两处先撤销普通入口、禁自动重认证，待Bridge.Close后再销毁会话。仅有单账号限制不足以豁免同账号重认证或关闭时序。
后续只围绕上述实际连接点形成完整方案，不先扩展81文件回调改造、身份全迁移或新的通用会话框架。