什么是 Snapshot、冷启动与热启动
一句话定义
CubeSandbox 的极速启动能力，本质上来自 对已经准备好的运行状态进行复用。
其中：
- 冷启动 是从更原始的起点把环境真正启动起来
- Snapshot 是把某个可复用状态固化下来
- 热启动 是基于这个已固化状态快速恢复实例
这三个概念不是并列功能，而是同一条性能链路上的三个环节。
为什么 CubeSandbox 必须依赖 Snapshot
如果每次创建 Sandbox 都要从最原始状态重新开始，平台将不可避免地付出这些成本：
- Guest 完整启动时间
- 语言运行时初始化时间
- 服务 ready 等待时间
- 文件与缓存准备时间
- 各种初始化过程带来的抖动
这意味着即使底层隔离能力再强，交付速度仍然会受到传统启动链路的限制。
CubeSandbox 要解决的恰恰是：
如何在保留强隔离的前提下，把“实例就绪”这件事做得像缓存命中一样快。
Snapshot 就是这件事的关键。
什么是冷启动
定义
冷启动指的是：
从更原始、未预热的基础状态开始，把一个环境真正启动并走到可运行、可服务的过程。
在 CubeSandbox 的语境里，冷启动通常发生在模板制作阶段，而不是每个用户请求阶段。
为什么冷启动仍然重要
很多人听到“热启动很快”，就误以为冷启动不重要了。
恰恰相反，冷启动非常重要，因为它负责完成那些无法凭空省略的准备工作：
- Guest 内核真正启动
- 用户态环境真正拉起
- 语言 / 服务运行时真正完成初始化
- 平台确认环境达到了可复用状态
可以说：
没有一次正确的冷启动，就不会有后续稳定的热启动。
冷启动的本质
冷启动不是为了用户即时体验，而是为了制造一个“值得复用”的状态基线。
所以在 CubeSandbox 里，冷启动更像是一次前置投资。
什么是 Snapshot
定义
Snapshot 是对某个运行状态的固化结果，使系统能够在后续快速恢复到这个状态，而不是重新从零初始化。
在 CubeSandbox 里，Snapshot 不是简单“存个文件”，而是高性能实例化模型的核心资产之一。
Snapshot 固化的是什么
从概念上讲，Snapshot 固化的是“已经准备好的系统状态”。
这通常意味着：
- Guest 已经完成一部分甚至大部分初始化
- 某些服务已经 ready
- 某些运行时已经被加载进内存
- 平台已经知道这是一个适合复制的时刻
Snapshot 真正节省的，不是磁盘拷贝，而是 重复初始化成本。
Snapshot 不是 Template 的全部，但通常是 Template 的核心能力之一
Template 是发布对象；Snapshot 是状态复用机制。
可以把两者理解为：
- Template 决定“这个环境是什么”
- Snapshot 决定“这个环境为什么能被快速交付”
什么是热启动
定义
热启动指的是：
基于已经准备好的模板与快照状态，快速恢复并交付一个新的 Sandbox，而不是从最原始状态重新完成整套启动流程。
为什么热启动不是“偷懒版启动”
热启动并不是少做了工作，而是把工作做在了更合适的时机：
- 应该复用的部分提前做好并冻结
- 不可共享的实例级状态在实例化时再补上
- 通过分层组织，让“共享基础”与“实例差异”解耦
所以热启动的本质不是简化逻辑，而是重排成本结构。
三者的关系：一条连续链路
最容易记住的关系是：
- 冷启动制造可复用状态
- Snapshot 固化可复用状态
- 热启动恢复并交付这个状态
如果只理解其中一个，而忽略另外两个，都会得出错误结论：
- 只讲冷启动，会觉得系统和普通 VM 没区别
- 只讲 Snapshot，会看不出它为何值得制作
- 只讲热启动，会误以为速度来自“神秘优化”
实际上它们是一条完整的因果链。
为什么 CubeSandbox 能做到“强隔离 + 快交付”
很多系统只能在两者之间做取舍：
- 要快，就用共享内核容器
- 要隔离，就接受传统 VM 启动成本
CubeSandbox 的设计目标不是在两者之间二选一，而是通过模板化和快照化，把“强隔离实例的初始化成本”尽量前移和摊薄。
换句话说，CubeSandbox 的关键创新不只是虚拟化本身，而是：
把虚拟化实例的启动过程产品化、模板化、快照化。
这才使得强隔离与低时延能够同时成立。
热启动到底快在什么地方
热启动快，不是因为 CPU 更快，也不主要是因为 I/O 更强，而是因为它少走了许多重复路径。
1. 少走了 Guest 从零引导路径
传统 VM 的完整引导链路非常长。
热启动通过复用已经准备好的状态，绕开了很多启动早期阶段。
2. 少走了运行时初始化路径
例如语言运行时、常驻服务、依赖加载等，往往都是高频重复成本。
3. 少走了平台 ready 判定等待
如果模板制作时已经把环境推到了稳定可用状态，那么实例创建时不需要每次重新等待整套准备过程。
Snapshot 带来的不只是“快”
1. 更稳定的交付时延
如果每次都从零初始化，时延波动会非常大。
基于 Snapshot 恢复，系统更容易获得稳定、可预测的交付时间。
2. 更高的并发扩展能力
在高并发场景下，重复做昂贵初始化会迅速放大资源压力。
Snapshot 让系统把很多成本集中在模板构建阶段，从而改善在线请求路径的压力结构。
3. 更强的一致性
相同 Template 对应的 Snapshot 能让一批实例从同一准备状态出发，这对可复现性和问题排查非常重要。
为什么“快照回滚”是更进一步的概念
一旦理解了“模板级快照用于快速创建实例”，就会发现更进一步的能力自然浮现出来：
- 在运行中的某个时间点保存状态
- 需要时回滚到那个时间点
- 从某个历史状态快速分叉多个新环境
这就是为什么快照能力不仅影响启动速度，还影响未来的：
- 并行探索
- 环境回放
- 分叉执行
- 调试与测试复现
也就是说，Snapshot 不是单点性能技巧，而是一种非常基础的状态组织能力。
什么状态能共享，什么状态不能共享
这是理解 Snapshot 时必须保持清醒的一点。
可共享的是模板级准备成果
例如：
- 已初始化好的基础环境
- 已就绪的常见运行时
- 可作为母版的内存 / 磁盘基线
不可直接共享的是实例级差异状态
例如：
- 当前用户代码执行结果
- 当前实例创建后的临时文件
- 实例独有网络连接
- 实例运行中的实时修改
所以 Snapshot 让系统“共享基础”，而不是“共享一切”。
常见误解
误解一：有快照就不需要模板
不对。
快照是机制，模板是平台对象。快照可以是模板的一部分，但不能替代模板的治理和发布语义。
误解二：热启动等于完全没有启动成本
不对。
热启动只是显著降低成本，而不是完全消灭成本。实例仍然需要：
- 获得自己的实例标识
- 建立自己的网络与路由
- 挂接自己的写时状态
- 完成必要的运行时接线
误解三：冷启动就是失败方案，热启动才是正确方案
不对。
冷启动和热启动不是好坏对立，而是分工不同：
- 冷启动负责准备与生产
- 热启动负责复用与交付
平台设计者最该关心什么
如果你站在平台或架构视角看，这个概念族最重要的不是“快照实现细节”，而是四个判断：
- 系统是否把昂贵初始化成功前移。
- 模板与快照的边界是否清晰。
- 共享状态与实例差异状态是否严格分层。
- 热启动性能是否建立在可治理、可重复的模板流程上。
和其它概念的关系
- 和 Template 的关系：Template 是母版对象，Snapshot 是其关键能力之一
- 和 Sandbox 的关系：Sandbox 是最终被交付的实例
- 和 MicroVM / Runtime / Guest 的关系：快照复用发生在这些运行时层之上
- 和 文件系统、镜像与可写层 的关系：共享基础与实例差异要靠分层状态组织实现
下一步
理解了实例为什么能快，下一步就该理解：
这些实例最终是如何分布在机器上、被谁管理、被谁调度的？
这就进入集群抽象： 什么是 Node、集群与调度。