Vercel Sandbox快照提速10倍：中位恢复仅250ms

快照性能的跨越式提升

Vercel 宣布其 Sandbox 产品的快照创建速度最高提升 10 倍，中位创建时间从 4.4 秒降至 0.4 秒以内。话说回来，快照恢复速度也提升了 50%，p50 恢复时间从 500 毫秒缩短到 250 毫秒。

这组数字背后是一个更值得关注的信号：沙箱环境的“状态保存与恢复”正在从一项辅助功能，变成开发工作流中的基础能力。对于依赖持久化沙箱的团队来说，快照速度直接决定了会话切换、任务恢复和并行实验的流畅程度。

VHS 格式如何实现提速

性能提升的核心来自 Vercel Hive Snapshot（VHS）格式的底层改造。新版本在数据索引方式上做了优化，使得更多的读写操作可以并行执行。

具体来看，快照的写入和恢复现在能够复用 VHS 格式内部的帧（frames），减少了重复的数据处理开销。恢复阶段，系统可以并行加载沙箱基础镜像和用户数据，而不是按顺序依次处理。这两项改动叠加，构成了创建速度大幅提升和恢复时间减半的技术基础。

从工程角度看，这种优化思路并不复杂——索引效率与并行度是存储系统性能的两个经典杠杆。但把它落在沙箱快照这种对延迟敏感的场景里，效果会被直接放大，因为每一次会话停止和恢复都会触发快照操作。

VHS（Vercel Hive Snapshot）格式是 Vercel 为其 Sandbox 产品自研的快照存储格式，名称中的“Hive”暗示其采用分片或分层的组织方式。与直接打包整个虚拟机磁盘镜像的传统做法不同，VHS 将沙箱状态切分为可独立寻址的“帧”（frames），并维护一套索引来记录各帧的位置与依赖关系。这种设计的关键价值在于：写入时只需记录新增或变更的帧，恢复时则可按索引并行拉取所需帧，而不必顺序扫描整个镜像。索引结构的好坏直接决定元数据查找的开销，因此文中提到的“索引方式优化”实质上是降低了每次快照操作的固定成本，这也是中位创建时间能压到亚秒级的前提。

在快照系统中，基础镜像（base image）与用户数据的分层是常见的架构选择。基础镜像包含操作系统、运行时和预装依赖，体量大但在同一沙箱模板下高度复用；用户数据则是会话期间产生的文件与状态变更，体量小但每次快照都不同。传统恢复流程往往先挂载基础镜像、再叠加用户数据层，两步存在先后依赖。Vercel 的改动让两者并行加载，相当于把恢复路径上的串行瓶颈拆开。需要注意的是，这种并行要求系统能正确处理两层之间的覆盖关系与一致性校验，否则可能出现用户数据先于基础镜像就绪的竞态问题，因此背后必然配套了相应的索引与合并逻辑。

默认行为与兼容性

持久化沙箱是 Vercel Sandbox 的默认模式，会话结束时自动创建快照，下次启动时从最新快照恢复。这一行为不需要任何配置，新的性能优化对所有新产生的快照自动生效。

已有的快照会保留旧格式，不会被自动迁移。这意味着存量用户不会因为格式变更而遇到兼容性问题，但也不会立即享受到新格式带来的速度提升。对于长期依赖快照的团队，逐步让旧快照自然淘汰、新会话使用新格式，是一个平滑的过渡路径。

**持久化沙箱（persistent sandbox）**指沙箱实例在会话结束后并不销毁，而是把完整状态保存下来、下次启动时原样恢复的运行模式。它与“临时沙箱”相对：后者每次启动都是干净环境，适合一次性任务；前者则适合需要保留文件、依赖安装结果和运行上下文的长期项目。持久化模式让沙箱更接近一台“随开随用”的远程开发机，但也把快照的创建与恢复频率推高到几乎每次会话切换都会触发，这正是快照延迟对体验影响被放大的原因。Vercel 将其设为默认行为，意味着大多数用户会在无感知的情况下频繁依赖快照路径。

对开发工作流的影响

快照创建时间进入亚秒级、恢复时间进入百毫秒级，改变的不只是单次操作的手感。在需要频繁启停沙箱的场景里——比如并行运行多个实验、在任务之间切换上下文、或者从失败中快速回滚——每次操作节省的时间会累积成可观的效率差异。

更实际的一点是，恢复速度提升到 250 毫秒意味着沙箱恢复已经接近“无感”的水平。开发者不再需要为等待环境就绪而调整自己的工作节奏，沙箱可以更自然地嵌入到交互式开发流程中。

Vercel 在公告中指向了快照文档，但没有透露 VHS 格式后续是否会有更多优化。从当前改动来看，索引效率和并行度的提升已经释放了明显的性能空间，而存量快照的格式兼容策略也说明这是一次渐进式演进，而非彻底重构。

文中反复出现的 p50 是延迟统计中的分位数指标，表示有 50% 的请求快于该数值，也就是中位数。与之常一起使用的是 p95、p99，用来刻画长尾延迟。对沙箱快照这类高频操作而言，p50 决定“典型体验”的流畅度，而 p99 决定少数慢请求会不会打断工作节奏。Vercel 公布的是 p50 数据，说明其优化主要改善了多数请求的常规路径；但评估实际体验时，还应关注高分段是否同步改善，否则个别慢恢复仍可能成为交互式开发中的卡顿来源。