6813da149a
保存独立KV用户服务、固定会话存档与原业务接线，以及C3d资料缓存和C3e本人统计写。 保留原PF/AGG路线、业务公式和时序；榜单读取、好友资料、公告、匹配及首场景闸仍待完成。 验证：ServiceHost两条件各33组646断言；Unity CLI Loop编译0错误269警告。 包含相关方案、评审裁决、测试及状态文档。未操作服务器、正式账号或打包。
61 lines
10 KiB
Markdown
61 lines
10 KiB
Markdown
# M2旧方法与调用方合并设计底稿（只读盘点，尚未送审）
|
||
|
||
日期：2026-09-29，主会话。B02修订2四入口已[限定关闭](../B02/B02-四入口实施复核裁决与限定关闭.md)。用户目标仍为：以KVMgr替代PlayFabMgr存档调用，保留原文件但最终无运行调用/自动执行；优先跑通，业务逻辑只作必要适配。本文记录下一大批设计依据，**尚不是可批准编码的完整方案**；未评审不得改下一批生产代码。
|
||
|
||
> **最新执行边界**：先完成旧存档能力与调用方的可核对移植，Guard及物理分层优化单列后续；此前“同批纠偏”表述不再有效。Guard是9月28日upserver迁移新增的，并非原始PlayFabMgr所固有；B02仅将带Guard的四KV入口原样搬到KVMgr。以[同生态位策略的来源核证与用户纠偏](M2-管理器同生态位替代策略-2026-09-29.md)为准。
|
||
|
||
> **层级纠偏（同日）**：用户指出底层KVMgr不能反向依赖外部Service。当前四入口虽然没有直接调用UserService，但`Core/KVMgr.cs`依赖`Services/PlayerData`中的加载guard；B02的等价复核不等于架构验收。本底稿的后续方向以[层级依赖纠偏意见](M2-KVMgr层级依赖纠偏意见-待审.md)为准：业务/Service→KVMgr→存储Handle/Owner，加载Service通过存储模块准入契约控制阶段，不允许KVMgr调用加载协调器或业务Service。当前源码尚未调整，须在完整方案审查后实施。
|
||
|
||
> **最新主会话裁决**：见[架构复审裁决与修复顺序](M2-架构复审裁决与修复顺序-2026-09-29.md)。现有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：`UpdateUserDataValue`167处、`GetLocalData`51处、立即同步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显式句柄入口，同时按[层级纠偏意见](M2-KVMgr层级依赖纠偏意见-待审.md)修正物理/逻辑依赖。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. 下一步把底稿补成可实施方案所需的证据
|
||
|
||
1. 对矩阵200个待迁移项，按**业务方法**归并相同key与同一动作，不把每条语法调用当一项审批。每组记录：是否仍在所选发布范围、可达配置、原PF路径、原操作来源、最早内存变化、KV保存key、成功UI/事件、失败停止点及测试入口。不能仅凭文件路径认定普通标记；读调用要跟同key写入和奖励动作一并追溯。
|
||
2. 对M2-A先判定真实无消费的状态组；对M2-B参考旧核心计划但排除不必要的队列/UI重排；M2-C查商业/活动的收款、领奖、回调；M2-D与4B3C/账号迁移政策衔接。
|
||
3. 列每波源文件白名单及各key的读写映射；修改前重算源码hash，确保B01/B02历史交付证据不回写。能复用现有测试则适配副本命中真实KVMgr，不重造镜像实现。
|
||
4. 验收每波失败/旧Owner/同账号新epoch/Unknown和必要业务回归；C前组合验收连续普通钓鱼与重启式重登。SDK直接调用、SignalR外围及平台打包按总TODO后续处理。
|
||
|
||
当前**明确未解**：正常登录后固定handle怎样由私有上下文安全交接/撤销、Editor限定的31模块绑定怎样最小转为正式构建、哪些旧调用实际可归入普通状态、以及200项中哪些业务要保留在本轮正式范围。这些都需要源码/产品范围证据，不能在编码时临场猜测。主会话将继续做这些核对，形成可审白名单与验收矩阵后再送原ZCode完整方案审查。
|
||
|
||
固定地址`http://s101.local:18080/`；Unity CLI Loop，不使用UnitySkills，暂不打包。本底稿仅只读扫描与文档，无代码、Play或正式请求。
|