6813da149a
保存独立KV用户服务、固定会话存档与原业务接线，以及C3d资料缓存和C3e本人统计写。 保留原PF/AGG路线、业务公式和时序；榜单读取、好友资料、公告、匹配及首场景闸仍待完成。 验证：ServiceHost两条件各33组646断言；Unity CLI Loop编译0错误269警告。 包含相关方案、评审裁决、测试及状态文档。未操作服务器、正式账号或打包。
31 lines
4.8 KiB
Markdown
31 lines
4.8 KiB
Markdown
# M2 客户端与服务端集中确认项
|
||
|
||
日期：2026-09-29。用户裁决：**KV 模式使用认证会话的新玩家 ID（`PlayerKVAccountDescriptor.PlayerId`）；原 PlayFab 玩家数据改经 KV 读写；原有游戏服请求沿用原逻辑。** 本 Agent 只处理客户端，不读取或修改本机、远程服务器代码。本文件只记录服务端实现依赖，不再向用户追问存储位置，也不对现有接口逐项索要 Swagger、路由和完整响应说明。
|
||
|
||
## 既有游戏服接口的新 ID 接线
|
||
|
||
现有游戏服接口若显式接收原 `playFabId`/`UserId`，KV 模式改传**新的玩家 ID**；原请求字段名、路由和业务流程保持现状。按用户指示，服务端开发侧接受新 ID 的兼容性由该侧核实；客户端不以逐项合同确认阻断接线。线上实测尚未完成，接线后做功能回归；只有出现具体不兼容时才记录接口、输入和响应并集中处理。
|
||
|
||
客户端已核：邮件 fetch/send/updateState 请求体没有 `playFabId`，请求身份由登录 Cookie 承载；`UserId` 只用于邮件本地缓存与同步游标分账号键，KV 将改用新 ID。好友邀请数请求体为空；俱乐部已有部分请求使用 `ApiPlayerId`；反作弊 `CheckBan` 明确发送 `playerID=userService.UserId`。这些都按上述原则接线，不再分别发起合同确认。
|
||
|
||
## 跨账号等级榜读取的实现依赖
|
||
|
||
用户已裁决：**KV 模式等级榜分数以 KV 为数据源，不再使用 PlayFab 统计存储。** 当前 KV 存档已有 `Lv` 和 `InfiniteBuildingData`，旧等级榜分数由等级乘 `100000` 再加建筑等级计算；客户端方案优先从这些已存 KV 值推导个人分数，避免未经评审重复存一份分数。`PlayerKVClient.Get/Set/Delete` 仅操作认证账号自己的 KV；旧等级榜另需全服/地区前 50 名及其他玩家资料，不能由客户端读取自己的 KV 后推算。服务端开发侧只需说明是否已有**从 KV 数据汇总的等级榜读取入口**；如果没有，则由该侧实现相应聚合读取并提供最小调用方式。本客户端 Agent 不读/改服务器代码，也不会伪造前 50 名或把个人分数当成全服榜。
|
||
|
||
`LeadboardData.GetLeaderboard` 的活动榜已通过现有 `event/GetLeaderboards` 游戏服请求，属于不同功能；沿用原流程并将显式玩家 ID 改为新 ID，不与等级榜聚合需求混为一谈。
|
||
|
||
问卷的旧 PlayFab 存档和十六进制 ID 抽样属于**客户端迁移**；`LoginDays`、邮件领奖、RT 重连等按原流程做客户端回归与旧会话保护。除非实测出现具体协议差异，不再要求服务端预先逐项解释原有接口。
|
||
|
||
## 跨账号公开资料读取
|
||
|
||
原 `UserService.GetPlayInfo/GetPlayLv` 在缓存缺失时调用 PlayFab 的 GetPlayerProfile/GetUserData；KV 自有档接口不能查询别人的公开档案。现有 Club、活动榜、伙伴等响应自带的资料直接复用；其余他人昵称、头像、等级、最后登录时间需要按**新 PlayerId**读取的公开资料入口。服务端侧提供已有入口及最小字段/错误语义即可，无需客户端查看服务端源码或再次裁定数据存储位置。客户端消费者包括社交/成员/伙伴列表，不能读本人KV代替对方，也不能用空成功伪装已迁移。
|
||
|
||
## 直接 PF 能力的替代（与普通游戏服请求区别）
|
||
|
||
- `FriendService.GetFriendList` 仍直接调用 PlayFab `GetFriendsListAsync`，包含好友关系、头像、昵称、统计和最后登录时间。AddFriend/DeleteFriend/SearchFriend等现有 `friend/*` 请求保持原逻辑/字段并传新ID；还需服务端侧指出已有的好友关系列表读取能力，若无则由该侧实现。客户端不猜测新的 `friend/GetFriendList` 路由。
|
||
- `Duel/UI/EventFishingDuelPanel.cs` 使用 PlayFab Multiplayer 创建/轮询/取消匹配票据及读取Match，旧EntityKey只属于PF。KV需对应的新ID匹配能力（创建、查询、取消、匹配结果/成员），不是把PlayerId塞进旧EntityKey即可。服务端侧说明可复用入口；客户端保留PF路线，未有依据前不伪造KV匹配成功。此项不阻断独立KV用户服务与个人存档编码，但阻断该功能最终通关。
|
||
|
||
以上条目来自具体客户端旧SDK调用，不是新增逐接口审批清单。邮件等既有游戏服接口不因此要求重做协议确认。多键KV与邮件状态跨系统崩溃窗口记录在合批正式方案奖励节；客户端不会声称ID替换同时获得事务保证。
|
||
|
||
首批正式 KV 仍限 **101、102 且已有 KV 档**，地址固定 `http://s101.local:18080/`。PF/AGG 模式保留原 PlayFab ID 和原路线；KV 不伪造 PlayFab ID/`EntityKey`。开发前完整方案评审、检查点日志、最终清理临时门控与闲置实现照常执行；不因本确认项拆成多轮审核。
|