第七部 · 高风险系统：NPC、物理、对象同步
这是第七部。NPC、物理、对象同步是最容易炸的几类系统。每章都要写「什么时候别做」，复杂系统先证明能降级。
这一部回答的核心问题
Section titled “这一部回答的核心问题”- NPC 的三种架构：local-only 装饰、Owner 驱动、分片 Owner
- 行为树在 UdonSharp 里的替代写法：枚举状态机 + 优先级表 + 数据驱动配置
- 对象池与生成系统：预放置、激活 / 关闭、Owner 分配、迟入恢复
VRC Object Sync与物理对象：能做什么、不能做什么- 对象同步生态对比：
SmartObjectSync稳定但已弃用，LightSync当前只作观察线索，Custom-Object-Sync作为高级技巧案例 - Quest 与多人实例下的性能预算
- 第二部第 11 章：
GameState Owner不是安全边界。NPC 由 Owner 驱动时同样要守这条边界。 - 第四部进阶：JSON / 字节打包能压缩对象池状态，但调试成本会上升。
- 第六部第 32 章：物理对象的修正与插值有边界。
NPC 是一种讲故事的方式：挑实现之前先挑功能。挑功能之前先挑这个 NPC 在世界里的角色。
主线（34–39 章）
Section titled “主线（34–39 章）”- 第 34 章 · NPC 的三种架构：local-only 装饰、Owner 驱动、分片 Owner。
- 第 35 章 · 行为树在 UdonSharp 里的替代写法：标准 BT 框架翻译成枚举状态机、优先级表和数据驱动配置。
- 第 36 章 · 对象池与生成系统：预放置、激活 / 关闭、Owner 分配、迟入恢复。
- 第 37 章 ·
VRCObjectSync与物理对象：空间同步、物理写权、重置和精确物理边界。 - 第 38 章 · 对象同步生态：官方、社区、技巧：官方组件优先，社区工具按维护状态和风险评估。
- 第 39 章 · Quest 与性能预算：先测量，再按渲染、脚本、网络三类预算降级。