沙箱磁盘由不同生命周期组成#

常见文件系统可以拆成：

镜像层与实例写层适合预热，因为它们不依赖用户身份。Workspace 则必须绑定正确租户，并在销毁实例后继续存在。

预热发生在身份绑定之前#

Warm Pool 通过提前完成镜像拉取、启动和运行时初始化降低冷启动。若预热实例已经挂载某个用户目录，它就不能安全分配给其他用户；若不挂载，领取后仍需执行挂载与权限配置。

因此更合理的流程是：

1
预热通用实例
2
→ 领取时绑定 Session 与租户
3
→ 挂载或接入 Workspace
4
→ 校验权限
5
→ 标记 Ready

Warm Pool 能省掉通用启动成本，不能省掉身份相关步骤。把“实例已启动”直接等同于“用户可执行”，会把挂载和权限延迟隐藏在 Ready 之后。

持久化有三种主要路径#

1. 网络挂载：跨节点继续使用，绑定简单，但受网络延迟与一致性影响；
2. 对象存储同步：实例启动和结束时导入导出，运行快，但同步窗口可能丢失中间状态；
3. 快照或块设备克隆：恢复速度稳定，但调度、容量与回收更复杂。

选择取决于 Workspace 是否必须实时持久、是否允许迁移节点，以及单任务数据量。没有一种路径同时获得本地盘性能、跨节点可用和零同步成本。

我的选择：Warm Pool 只预热无身份部分#

我会让池中实例只包含公共镜像和运行时，把 Workspace、凭据与租户策略推迟到领取阶段。Ready 指标拆分为实例启动、身份绑定、挂载和可执行四段。

如果用户状态不需要留在沙箱本地，优先把结果写入外部存储，Warm Pool 最容易复用。若必须持续挂载私有 Workspace，就接受领取阶段仍有绑定成本，并根据数据一致性选择网络挂载或块存储。

这套方案牺牲了部分“瞬时可用”的宣传数字，却能保证池中实例没有残留前一租户数据，也不会把身份相关初始化误算为已完成。