第二部 · 玩家对象与权威拓扑
这是第二部。读这一部之前建议先做完闭环 1，亲眼看到 Master 离开整局丢失、Ready 状态互相覆盖这两个问题。
第一部把通道讲清楚后，下一个问题是：谁能改这些状态。VRChat 没有权威服务器，权威拓扑要在写代码之前就设计好。代码里到处出现 SetOwner() 通常意味着权威拓扑还没想清楚。
这一部回答的核心问题
Section titled “这一部回答的核心问题”- 玩家进入房间后，系统要给他什么：身份、准备、队伍、输入通道、个人 UI
VRCPlayerObject：每位玩家固定拥有自己的对象。它适合什么、不适合什么CyanPlayerObjectPool：作为历史方案与兼容案例理解- 全局状态管理器（
GameState）的三种 Owner 策略：固定 Owner、Owner 候选队列、Owner 重选 - 请求式架构：玩家对象请求，状态管理器裁决（本部给出固定代码模板，后续章节复用）
- 权限与冲突：抢按钮、抢拾取、同时加入队伍
- Owner 离开后，玩家对象、全局状态、物理对象的不同恢复路径
- 第一部第 3 章：Owner 是「这份状态托管在谁那里」。
IsMaster是旧逻辑，新系统不再当作默认权威。 - 第一部第 5 章：事件不会重放，迟入玩家只能拿到当前同步状态。
- 第一部理解章 A：同步不是广播，是状态复制。每份状态都有一个明确的托管者。
- 闭环 1 留下的两个缺陷：Master 离开整局丢失；每位玩家的 Ready 状态共用一份字段，会互相覆盖。
每位玩家有自己的轨迹：分权的理由不是省带宽，是承认每位玩家本身就承载着独立的一组状态。
主线（8–14 章）
Section titled “主线（8–14 章）”- 第 8 章 · 玩家进入房间后，系统要给他什么（占位）
- 第 9 章 ·
VRCPlayerObject：每个玩家一份对象（占位，含 PlayerObject 适合 / 不适合什么的清单） - 第 10 章 ·
CyanPlayerObjectPool：历史方案与兼容案例（占位） - 第 11 章 · 全局状态管理器（占位，含「什么世界不需要 GameState」反向案例）
- 第 12 章 · 请求式架构：固定模板（占位，给 PlayerObject + GameState 的代码骨架）
- 第 13 章 · 权限与冲突（占位）
- 第 14 章 · Owner 离开后的恢复（占位，含「Owner 失效恢复检查表」）
- 🧠 理解章 B · 权威拓扑先于代码（占位）
- ★ 闭环 2 · PlayerObject + GameState 的中级一局（占位）
修复闭环 1 的两个缺陷，故意留下三个新缺陷待第四部修：重复点击会重复加分；网络抖动后状态版本会乱；迟入玩家可能看到串味状态。 - 📚 对照小练 B · 用 PlayerObject 做两人回合制猜数字（占位）
章节正在筹备。