第七部 · 高风险系统：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 的三种架构（占位）
- 第 35 章 · 行为树在 UdonSharp 里的替代写法（占位，含一篇翻译章：标准 BT 框架 → UdonSharp 替代）
- 第 36 章 · 对象池与生成系统（占位）
- 第 37 章 ·
VRCObjectSync与物理对象（占位） - 第 38 章 · 对象同步生态：官方、社区、技巧（占位，合并章）
- 第 39 章 · Quest 与性能预算（占位）
- 🧠 理解章 G · 复杂系统先证明能降级（占位）
章节正在筹备。