开场
凌晨两点，美术同学反馈：角色身上挂了三个动画状态机，Profiler 显示动画更新在主线程飙到 12ms。你打开 Timeline 想优化，却发现 AnimationClip 之间的混合完全是黑盒——混合权重在哪一步算？求值顺序谁先谁后？为什么 AnimationMixerPlayable 多加几个输入就开始掉帧？
更崩溃的是你想打断点跟一下，却发现 C# 层的PlayableHandle只是个不透明的句柄，真正的逻辑全在 native 层。句柄背后到底藏着什么？Graph 的求值顺序怎么决定？这些谜题不解决，所谓"优化"就只能是猜参数。今天我们就钻进 Playable API 的架构里，把这套内容驱动系统的骨架拆开。需要说明的是：Unity 未公开 Playable 内核源码，本文对 native 层的描述基于官方文档、反编译的托管层封装与公开资料的综合推断，数据结构细节以"概念示意"呈现。
一、PlayableGraph：一张有向无环图的内容流骨架
1.1 它解决什么问题
在 Playable 出现之前，动画混合靠 Animator 状态机、音频靠 AudioSource、过场靠各写各的协程——三套系统互不通信。Playable API 的统一抽象是：所有"随时间流动的内容"都是图上的节点，内容沿边从源节点流向输出节点。动画剪辑、音频剪辑、视频、脚本逻辑，全部归一到同一张有向无环图（DAG）里求值。Timeline（PlayableDirector）和 Animator 的底层都是这套图。
1.2 句柄设计：C# 与 C++ 的安全隔离带
C# 层拿到的P
