普通视频是一条固定的时间线，播放器只要管 seek 和缓冲。互动视频不是——它在特定时刻停住给观众几个选项，选完才知道下一段播什么。

这个区别一旦落到实现上，就不只是「多几个按钮」那么简单。这篇文章记录把剧情建模成有向图之后真正需要解决的三个工程问题：预加载该预取哪几条分支、选择界面的背景帧从哪来还有为什么结构选错会让制作量指数爆炸。怎么说呢，

一、数据结构：从数组到有向图

线性视频的模型是 Clip互动视频的模型是一张有向图：节点是场景，边是选择。

最小可用的类型定义大致长这样：

type NodeId = string;interface StoryNode {
id这方面，NodeId;video: string;next，: NodeId;// 线性续接
choices?其实，: Choice，// 或者分叉，二选一
effects?: Record;怎么说呢，// 走到这个节点时写变量
}
interface Choice {
从label来看。string，target: NodeId;if，: string;老实说，// 条件表达式，不满足则不展示这个选项
}

next 和 choices 互斥：有 next 就是线性节点。有 choices 就是选择点。这个约束值得在校验层强制，否则运行时要处理一堆歧义状态。

二、状态机：让第一集的决定影响第三集

只有跳转的话，这就是个流程图。真正让它变成状态机的是变量——effects 写，if 读。话说回来，

如果条件评估太慢或不安全。会导致卡顿甚至安全漏洞，

内容作者往往不想写复杂脚本，只能用简单表达式。

动态条件可能导致 UI 冲突和不可预测行为。

调试条件错误难以定位，需要可视化工具支持。

我们提供一个受限求值器，而不是直接用 eval：

type Vars = Record;const OPS: Record boolean> = {
'>='这方面。=>a>=b,'<=':=>a<=b,
  '>':=>a>b,'<':=>a