6813da149a
保存独立KV用户服务、固定会话存档与原业务接线，以及C3d资料缓存和C3e本人统计写。 保留原PF/AGG路线、业务公式和时序；榜单读取、好友资料、公告、匹配及首场景闸仍待完成。 验证：ServiceHost两条件各33组646断言；Unity CLI Loop编译0错误269警告。 包含相关方案、评审裁决、测试及状态文档。未操作服务器、正式账号或打包。
102 lines
5.4 KiB
Markdown
102 lines
5.4 KiB
Markdown
# M2正式接线依赖独立复审（修订2）
|
||
|
||
日期：2026-09-29。审查者：ZCode会话（M2修订1审查者）。本轮只读＋hash重算＋源码核对；未修改任何生产/测试源码/共享文档/历史报告。
|
||
|
||
## 受审hash核对
|
||
|
||
`M2-正式接线依赖受审基线-修订2.json`：**19/19重算全部一致**。
|
||
|
||
## 总裁决
|
||
|
||
| 对象 | 结论 |
|
||
|---|---|
|
||
| **CP1限定实施白名单** | **通过**（可批准编码） |
|
||
| **CP2前置设计盘点** | **通过**（五类阻断准确完整） |
|
||
|
||
无P1；P2一条；P3一条。
|
||
|
||
## 主会话新增事实复核
|
||
|
||
本审查独立核证全部四项：
|
||
|
||
| 事实 | 源码证据 | 对修订1判断的影响 |
|
||
|---|---|---|
|
||
| 普通启动无条件创建PF组件 | `SubBoostrap.cs:91 AddComponent<PlayFabMgr>()` | ✓ CP1不能要求"PF未启动"同时又沿用普通启动 |
|
||
| `kv`配置被拒 | `UserService.KVLoad.cs:17-23` `BackendNotEnabled` | ✓ 正式登录路径完全未接通 |
|
||
| 账号租约仅验证路由 | `CustomServerMgr.cs:45/53/65` `kvOnly`＋仅两条验证路径 | ✓ 正式业务API借用被阻断 |
|
||
| Bindings仅Editor | `PlayerKVGameplayBindings.cs:1` `#if UNITY_EDITOR && !SERVICE_HOST` | ✓ Player构建无31模块绑定 |
|
||
|
||
**对修订1"30–50行"判断的修正**：我当时的估算仅覆盖Coordinator内的Guard释放/handle交接——主会话指出的五类启动/认证/工厂/绑定/路由阻断确实不在其中。**修订2正确识别了"加载→释放→交接"（CP1）与"正式接线"（CP2）是两个不同系统边界**——这一拆分使CP1可在合成环境独立验证而不需先解决全部启动问题。
|
||
|
||
## CP1限定实施白名单裁决：通过
|
||
|
||
### 三个internal签名审查
|
||
|
||
**1. `PlayerKVLoginContext.TryAcquireGameHandle(long expectedEpoch, out handle)`**
|
||
- 条件链（prepared/未closing/未revoked/IsCurrent/epoch匹配）→返回现存原对象——**不创建新Owner、不公开Cookie**——正确；
|
||
- "取得句柄不代表公布可写状态，最终发布由协调器做"——两步交接（Context给→Coordinator发布）——**防止中间态泄漏**。
|
||
|
||
**2. `Coordinator.LoadForGameAsync(id, capability, token, identityCurrent)`**
|
||
- **共用现有Prepare/Decode/Apply主体，不复制200行**——满足用户最小代码要求；
|
||
- 成功时序：`Apply返回None→notify完成→epoch/context/Violations复核→取得原handle→释放Guard→发布GameLoaded`——精确且与Editor已验证时序一致（Apply后释放）；
|
||
- "失败继续原Revoke/Close；不得仅使KVMgr忽略Guard"——**不绕Guard**——正确。
|
||
|
||
**3. `Coordinator.TryGetCurrentGameHandle(epoch, out handle)`**
|
||
- 仅正式成功＋Guard已释放才返回——防止加载期间外泄；
|
||
- `Revoke`同步清除引用先于关闭排水——正确顺序。
|
||
|
||
### Guard/KVMgr保持原样
|
||
|
||
§2.4明确"Guard.cs及KVMgr.cs四入口方法体原样保持"——与用户"现阶段不动Guard"一致。
|
||
|
||
### 白名单精确
|
||
|
||
仅`PlayerKVLoginContext.cs`＋`PlayerKVGameLoadCoordinator.cs`＋合成测试宿主——**3个文件的改动面**，远小于此前任何批次。
|
||
|
||
### 并发测试覆盖
|
||
|
||
"Guard释放/状态发布/Revoke并发锁顺序列入实施测试，不在锁内await"——覆盖了关键竞争。
|
||
|
||
### CP1不会成为弃用代码
|
||
|
||
CP1的三个接口在CP2中**必须实际使用**（§1"若CP2评审认为不适用，应在合并前删掉"）——正确的防废措施。具体而言：
|
||
- `TryAcquireGameHandle`→CP2的正式登录完成后获取句柄
|
||
- `LoadForGameAsync`→CP2的正式加载入口
|
||
- `TryGetCurrentGameHandle`→CP2的业务操作获取可写句柄
|
||
|
||
**P2-1**：建议主会话裁决时将"CP1接口在CP2中的实际消费点"列表（3个接口各自被CP2的哪个具体场景调用），作为CP2设计的输入——使CP1→CP2的接口衔接在设计阶段即有闭环。
|
||
|
||
## CP2前置设计盘点裁决：通过
|
||
|
||
五类阻断（§3表格）全部源码核实属实，每类的"CP2所需设计证据"完整：
|
||
|
||
| 类别 | 阻断 | CP2设计要求 | 完整性 |
|
||
|---|---|---|---|
|
||
| 启动 | AddComponent无条件创建 | backend分流创建 | ✓ |
|
||
| 认证 | kv被拒/登录PF先行 | KV分支单S101认证/错误码/IsLogin | ✓ |
|
||
| 工厂 | 仅Editor验证工厂 | 正式工厂（API/Cookie/handler/CacheRoot） | ✓ |
|
||
| 绑定 | Bindings仅Editor | 提升Bind进Player编译/逐模块核注册 | ✓ |
|
||
| 网络 | 租约仅验证路由 | 单会话租约承接正式API/按域白名单 | ✓ |
|
||
|
||
**"CP2范围显著超过修订1估计的30–50行"**——本审查接受此修正。
|
||
|
||
## P2/P3落实检查
|
||
|
||
| 项 | 主会话裁决 | 修订2落实 | 判断 |
|
||
|---|---|---|---|
|
||
| P2-1（5项签名） | CP1条件不足 | §2三签名精确给出 | ✓ 落实 |
|
||
| P3-1（Guard映射） | 20处/5文件核证 | §4记录，不随CP1移动 | ✓ 落实（20处方法调用vs旧报告21处引用——计数口径差异已解释） |
|
||
| P3-2（PF触发差异） | CP3各域记录 | §4 CP4停用前对账 | ✓ 落实 |
|
||
| P3-3（Player编译） | 历史错误单列 | §4 CP1"未声称Player通过"＋CP2要求0错误 | ✓ 落实 |
|
||
|
||
## P3清单
|
||
|
||
- **P3-1**：如上述P2-1建议——CP2设计时列表CP1三接口的消费点，确保接口闭环。
|
||
|
||
## 结论
|
||
|
||
**CP1通过（可批准编码）。CP2前置设计通过（待完整设计审查后实施）。** 主会话核hash（已代验19/19）裁决后：
|
||
1. 按CP1白名单实施（LoginContext＋Coordinator＋合成测试）；
|
||
2. CP1批末独立实施复核；
|
||
3. 并行准备CP2完整设计（正式启动/认证/工厂/绑定/路由五类）。
|