Files

$Liubing\LB$ Liubing\LB 6813da149a feat(upserver): 保存M2客户端KV迁移至本人统计写检查点

保存独立KV用户服务、固定会话存档与原业务接线，以及C3d资料缓存和C3e本人统计写。
保留原PF/AGG路线、业务公式和时序；榜单读取、好友资料、公告、匹配及首场景闸仍待完成。

验证：ServiceHost两条件各33组646断言；Unity CLI Loop编译0错误269警告。
包含相关方案、评审裁决、测试及状态文档。未操作服务器、正式账号或打包。

2026-09-30 19:19:05 +08:00

10 KiB

Raw Blame History

M2旧方法与调用方合并设计底稿（只读盘点，尚未送审）

日期：2026-09-29，主会话。B02修订2四入口已限定关闭。用户目标仍为：以KVMgr替代PlayFabMgr存档调用，保留原文件但最终无运行调用/自动执行；优先跑通，业务逻辑只作必要适配。本文记录下一大批设计依据，尚不是可批准编码的完整方案；未评审不得改下一批生产代码。

最新执行边界：先完成旧存档能力与调用方的可核对移植，Guard及物理分层优化单列后续；此前“同批纠偏”表述不再有效。Guard是9月28日upserver迁移新增的，并非原始PlayFabMgr所固有；B02仅将带Guard的四KV入口原样搬到KVMgr。以同生态位策略的来源核证与用户纠偏为准。

层级纠偏（同日）：用户指出底层KVMgr不能反向依赖外部Service。当前四入口虽然没有直接调用UserService，但Core/KVMgr.cs依赖Services/PlayerData中的加载guard；B02的等价复核不等于架构验收。本底稿的后续方向以层级依赖纠偏意见为准：业务/Service→KVMgr→存储Handle/Owner，加载Service通过存储模块准入契约控制阶段，不允许KVMgr调用加载协调器或业务Service。当前源码尚未调整，须在完整方案审查后实施。

最新主会话裁决：见架构复审裁决与修复顺序。现有guard自身不调用上层Service；优先归位KVMgr并保留单一guard的语义，不预设新造准入状态。本文四波是全局盘点，当前只准备R1第一批完整方案。

1. 当前证据与完成度

复用既有B3DesignAudit只读Roslyn扫描器，对当前2109个Client/Assets/Scripts源码文件在五套编译条件下重新扫描，结果仍为224个语法候选/81个文件。新current-scan/calls.json与旧224项按路径、成员、方法及参数完整对应（丢失0、新增0）；M2-当前调用矩阵-待核证.json逐项连接旧分类与当前源码hash。没有把KVMgr四个已迁出入口重复计入旧候选。该盘点不是完整上游、运行可达或业务安全证明。

既有分类	候选调用	说明
待迁移分类	200	仍须按真实业务与归属设计
保留PF待专项	13	原暂缓类别；最终清零时也必须转移/隔离，不能永久留PF
已有限定处理、正式仍待	4	不能把测试路径直接作为正式发布
B业务实现关闭、待C接线	3	B01已关闭，正式生产注册未切换
本次排除	4	GM/调试用；最终零引用检查要决定替代、隔离或删除

按旧批次初分：普通业务写约103、活动/奖励关联69、读取/初始化20；此外身份/公共资料13、C生命周期8、已处理/GM等。PlayFabMgr.Instance.方法(...)直接文本快照另见B02/Tests/Compatibility/remaining-legacy-call-scan.json：UpdateUserDataValue167处、GetLocalData51处、立即同步2处、CompareDatas1处。两种扫描器口径不同，不相加、不当完成率。直接引用外还要核别名、UnityEvent/Prefab、反射及组件注册。

2. 关键事实与路线

KVMgr已提供ReadKV/WriteKV/FlushKVAsync/WaitForKVTicketAsync，全部显式接收固定PlayerKVGameSessionHandle，不需要重造缓存或同步引擎。
旧GetLocalData返回string/null；KV读取有成功且缺键、成功且存在空串、失败三态。不能做同签名直接替换后把错误折叠为null。
旧UpdateUserDataValue返回void；KV写入可能Rejected、Accepted或本地提交不确定。不能用void吞结果后继续发奖/显示成功。
旧SyncDataImmidiate返回bool；KV必须观察该次原票据的远端状态。Unknown不能判已失败后自动重试，也不能判成功。
当前正常配置仍将SaveBackend=kv拒绝；UserService.KVLoad的正式会话发布、加载后的可写状态、暂停/退出接线未完成。测试用PlayerKVGameplayLoop.Capture()仅限Editor许可，不能成为生产调用路由。
固定句柄目前没有正式交接出口：PlayerKVLoginContext持有私有handle，其TryAcquireAccountLease给CustomServerMgr的是账号网络租约，不是PlayerKVGameSessionHandle；PlayerKVGameLoadCoordinator.LoadAsync成功只返回阶段/epoch/模块数等证据。既有PlayerKVGameplayBindings.Bind整文件受UNITY_EDITOR && !SERVICE_HOST约束，供测试循环绑定31模块，不能直接当Player构建的正式注册。UserService.LoginCore在非Editor测试循环时仍走LoginPlayFab。因此任何旧调用方都不能简单从受控加载结果取到可写Owner。
PlayerKVGameLoadCapability.CreateForValidation和PlayFabUserService.ConfigureKVForValidation仍明确为受控验证工厂/入口；普通PlayFabUserService()没有kvControlledInstance，其IsLogin及未授权重登仍依赖PlayFab客户端状态。正式路径不是给现有验证入口换一个配置值即可。C级认证/加载注册合同须纳入同一合并方案的先决章节，不能实施时临时放开受控门。
SubBoostrap仍创建PlayFabMgr组件；其旧PF方法与定时/暂停/退出仍在。本大批完成前不能停用组件，也不能先删SDK包。

选择方向：沿用现有四个KVMgr显式句柄入口，同时按层级纠偏意见修正物理/逻辑依赖。KVMgr属于存储层，不能向上调用登录/加载Service；加载编排从上层控制存储准入并交接原handle。方案须增加受控的正式句柄交接：成功Prepare且31模块Apply/通知均成功后，会话拥有者才把原handle绑定到该账号模型或操作；拒绝、撤销、登出/旧epoch时先阻断新动作，随后清除绑定并等待Close屏障。交接必须核实PlayerKVLoginContext的私有句柄与PlayerKVGameLoadCoordinator阶段，不能把账号租约传给KVMgr。同步普通状态的生命周期与异步消费操作分别处理；每处旧调用转KV时处理实际返回，不新增全局“当前账号”、隐式线程上下文、旧Mgr转发壳或第二套数据仓库。默认PF路径切换必须以迁移范围和账号/故障前置为门，不仅改配置。

3. 一份合并方案下的较大业务波次

本表是设计分流，并非直接代码白名单。后续应把同波次的上游方法、首次模型修改、key、固定Owner来源和错误/确认规则写成矩阵，再提交一次完整批级方案审查。波次内合同错误直接修复和回归，每检查点更新日志；不按单个调用拆审批。

波次	关联模块与现有依据	必须回答的合同
M2-A：正式Owner交接与低风险状态	先设计正式会话交接/撤销；仅将已证实无消费、无奖励、无延迟回调的普通标记纳入首批，复用B01模式	Apply前不可发布句柄；合法缺键与失败分开；拒绝写入不显示成功；退出/旧epoch后句柄不得继续使用
M2-B：核心进度与资源/奖励	等级、鱼竿、地图、引导、鱼卡包/箱及其奖励依赖；修订1的185源码锚点/静态掉落盘点保留作参考	首次扣费/升级/领取前绑定原操作；多键票据、随机只算一次、延迟UI；只做存储迁移所必需的最小业务修正，原公式与内容保持
M2-C：活动、商业与延迟回调	旧分类69个活动/奖励关联候选，商店、广告、支付、转盘等跨模块事件；不可把所有调用假定为普通标记	资格/消费/奖励是否同操作；迟到回调隔离；Unknown/部分成功停止；活动/战令/成就等接收方不静默漏记
M2-D：身份、加载与生命周期收口	UserService/CompareDatas，旧Mgr内部PF同步，C正式Load/发布/定时/暂停/退出，SubBoostrap组件，GM及UI/Prefab/反射引用	账号来源/历史档和新账号建档、非空目标；原Owner关闭；全部运行调用与自动执行归零；禁用旧PF回退；旧文件SDK类型移除时仍能编译

这四波的依赖并非严格从A到D单向：正式会话固定Owner的设计必须先于A/B/C实施确定；M2-D的正式默认启用则必须等纳入发布的业务和T08/C多键部分保存恢复条件具备。计划中的临时受控验证只能证明B层合同，不能称默认KV已经发布。旧分类的20个读取/初始化调用实际涉及充值时间、活动、PVP、延迟奖励、好友奖励、广告轮盘等；它们不能整体归为普通标记，必须与对应写入和领取动作合并审查。

4. 下一步把底稿补成可实施方案所需的证据

对矩阵200个待迁移项，按业务方法归并相同key与同一动作，不把每条语法调用当一项审批。每组记录：是否仍在所选发布范围、可达配置、原PF路径、原操作来源、最早内存变化、KV保存key、成功UI/事件、失败停止点及测试入口。不能仅凭文件路径认定普通标记；读调用要跟同key写入和奖励动作一并追溯。
对M2-A先判定真实无消费的状态组；对M2-B参考旧核心计划但排除不必要的队列/UI重排；M2-C查商业/活动的收款、领奖、回调；M2-D与4B3C/账号迁移政策衔接。
列每波源文件白名单及各key的读写映射；修改前重算源码hash，确保B01/B02历史交付证据不回写。能复用现有测试则适配副本命中真实KVMgr，不重造镜像实现。
验收每波失败/旧Owner/同账号新epoch/Unknown和必要业务回归；C前组合验收连续普通钓鱼与重启式重登。SDK直接调用、SignalR外围及平台打包按总TODO后续处理。

当前明确未解：正常登录后固定handle怎样由私有上下文安全交接/撤销、Editor限定的31模块绑定怎样最小转为正式构建、哪些旧调用实际可归入普通状态、以及200项中哪些业务要保留在本轮正式范围。这些都需要源码/产品范围证据，不能在编码时临场猜测。主会话将继续做这些核对，形成可审白名单与验收矩阵后再送原ZCode完整方案审查。

固定地址http://s101.local:18080/；Unity CLI Loop，不使用UnitySkills，暂不打包。本底稿仅只读扫描与文档，无代码、Play或正式请求。

10 KiB Raw Blame History Unescape Escape