6813da149a
保存独立KV用户服务、固定会话存档与原业务接线，以及C3d资料缓存和C3e本人统计写。 保留原PF/AGG路线、业务公式和时序；榜单读取、好友资料、公告、匹配及首场景闸仍待完成。 验证：ServiceHost两条件各33组646断言；Unity CLI Loop编译0错误269警告。 包含相关方案、评审裁决、测试及状态文档。未操作服务器、正式账号或打包。
80 lines
5.3 KiB
Markdown
80 lines
5.3 KiB
Markdown
# M2架构纠偏意见与设计底稿独立审查
|
||
|
||
日期：2026-09-29。审查者：ZCode会话（B02全链审查者）。独立性声明：未参与纠偏意见或底稿编写；B02四入口实施复核为本审查者产出。本轮只读＋hash/源码核对。
|
||
|
||
## 总裁决
|
||
|
||
**纠偏意见：接受。设计底稿：方向正确，尚不可批准编码（底稿自身也如此定位）。**
|
||
|
||
## 一、架构纠偏意见审查
|
||
|
||
### 依赖方向问题确认
|
||
|
||
本审查源码核实：`Core/KVMgr.cs`使用`using game.PlayerDataStorage`并调用`PlayerKVGameLoadGuard.Reject`——而`PlayerKVGameLoadGuard`位于`Services/PlayerData/PlayerKVGameLoadGuard.cs`，由`PlayerKVGameLoadCoordinator`（加载编排层）控制。**这确实是底层存档入口对上层编排规则的反向依赖。**
|
||
|
||
### 纠偏的责任归属分析：准确
|
||
|
||
纠偏意见正确指出：
|
||
- B02的目标是"逐字行为等价搬迁"——guard检查从原PlayFabMgr**原样搬入**KVMgr——这是**等价性的要求**，不是架构认可；
|
||
- **"等价复核PASS证明等价和兼容，不证明层级设计正确"**——这是对我B02复核结论的准确限定。我在复核中确认的是行为等价（逐行比对），没有评估架构方向——因为我审查的合同就是等价搬迁；
|
||
- 主会话主动撤回"等价→可沿此结构扩展"的推论——**正确的自我纠错**。
|
||
|
||
### 推荐路线评估
|
||
|
||
三方案比较合理。推荐方案（"存储模块内薄KVMgr＋下沉准入契约"）：
|
||
- **不新增全局当前账号或第二套缓存**——仅把guard状态抽为存储模块内的准入契约；
|
||
- 上层加载编排调用Enter/Exit，KVMgr只查同模块状态——**依赖方向修正**；
|
||
- 改动面最小（不需要抽取Handle/Owner/结果类型到Core接口）；
|
||
- 不采用方案2（接口抽取改动面大）和方案3（保持现状继续强化反向依赖）——**否决理由正确**。
|
||
|
||
### 一项补充
|
||
|
||
"是否移动guard本体或抽出共享最小状态，须以21处guard引用和加载竞争测试为边界做完整设计"——本审查核实guard引用分布（PlayerKVGameLoadCoordinator/EditorValidationHost等），确认21处引用的存在。建议后续完整方案中**先做一个guard引用映射表**（每处引用的文件/用途/是否需要保留），作为准入契约设计的输入。
|
||
|
||
## 二、设计底稿审查
|
||
|
||
### 关键发现确认
|
||
|
||
**1. 正式句柄交接缺口——底稿最重要的发现。**
|
||
|
||
本审查核实：`PlayerKVLoginContext`内部持有`handle`（私有），其`TryAcquireAccountLease`提供的是**账号网络租约**（HttpMessageHandler），不是`PlayerKVGameSessionHandle`。`PlayerKVGameLoadCoordinator.LoadAsync`成功只返回阶段证据。`PlayerKVGameplayBindings.Bind`受`UNITY_EDITOR && !SERVICE_HOST`限定。
|
||
|
||
**结论：当前没有任何Player构建的正式路径能从受控加载获得可写KV句柄**——这是4B3C的核心缺口，底稿正确识别为"任何旧调用方都不能简单从受控加载结果取到可写Owner"。
|
||
|
||
**2. 224候选盘点更新——准确。**
|
||
|
||
当前扫描2109文件→224语法候选/81文件，与旧calls.json完整映射（丢失0/新增0）。分类：待迁移200/保留PF 13/已有限定4/B关闭待C 3/排除4——总数匹配。
|
||
|
||
**3. `UpdateUserDataValue`167处/`GetLocalData`51处的文本快照**——与此前B3盘点口径一致。底稿正确声明"两种扫描器口径不同，不相加、不当完成率"。
|
||
|
||
### 四波分流评估
|
||
|
||
| 波次 | 范围 | 判断 |
|
||
|---|---|---|
|
||
| M2-A 正式Owner交接＋低风险状态 | 先设计正式句柄交接→B01模式扩展 | **正确的首波**——正式交接是A/B/C共同前置 |
|
||
| M2-B 核心进度 | 等级/鱼竿/地图/引导/奖励 | 参考修订1但不重排——用户最新意图 |
|
||
| M2-C 活动/商业/延迟回调 | 69个活动关联＋商店/广告/支付 | 最复杂——涉及消费/奖励合同 |
|
||
| M2-D 身份/加载/生命周期收口 | CompareDatas/正式Load/组件退出/SDK清理 | 最终收尾 |
|
||
|
||
**依赖方向**："正式Owner交接须先于A/B/C确定"——正确；"M2-D默认启用须等T08/C多键恢复"——P2-1正确承接。
|
||
|
||
### 底稿尚不可批准的原因（底稿自身声明一致）
|
||
|
||
1. 200个待迁移项尚未按业务方法归并（§4第1条）
|
||
2. M2-A的真实无消费状态组未判定
|
||
3. 正式句柄交接的具体设计未完成
|
||
4. guard下沉的具体方案（本体移动vs抽共享状态）未定
|
||
5. 文件白名单未编制
|
||
|
||
## 三、审查侧建议
|
||
|
||
1. **M2完整方案的最小可批准单元**：建议首份可审方案覆盖"架构纠偏（guard下沉＋KVMgr归位）＋正式句柄交接＋M2-A首批普通标记"——三者互相依赖，一起设计一次审查比拆三份各自审更高效。
|
||
|
||
2. **guard引用映射表**：作为M2方案的必备附件——21处引用的文件/用途/控制方向/是否需要随guard迁移。
|
||
|
||
3. **修订1资产复用**：185源码锚点＋2400Drop盘点保留为M2-B参考——不重做已有工作。修订1的业务合同（队列不提前扣费/随机一次/多键票据确认）在M2-B实施时按需纳入，不作为前置。
|
||
|
||
## 结论
|
||
|
||
**纠偏意见接受；底稿方向正确，待补全为完整方案后一次性审查。** 主会话下一步：补全正式句柄交接设计＋guard下沉方案＋M2-A首批白名单→交一份合并方案→独立审查→裁决→实施。
|