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

5.4 KiB

Raw Blame History

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）裁决后：

按CP1白名单实施（LoginContext＋Coordinator＋合成测试）；
CP1批末独立实施复核；
并行准备CP2完整设计（正式启动/认证/工厂/绑定/路由五类）。

5.4 KiB Raw Blame History Unescape Escape