第 21 章：把同一个任务放进四项工程
用销售表格做共同题目
继续使用第 8 章的三笔虚构收入，目标始终是输出总额 250。比较时先固定任务，再观察工程如何解决环境、执行、网络、持久化和清理。下面是概念迁移练习，不是未经运行就宣称可直接使用的 SDK 示例。
| 环节 | OpenSandbox | SPACE | CubeSandbox | sandbox-runtime |
|---|---|---|---|---|
| 准备环境 | 选择后端与镜像或模板 | 选择模板并创建 microVM | 选择模板，经控制面安排实例 | 使用现有主机与工作目录 |
| 提交计算 | SDK 经 execd 执行 | 建命令会话，attach 执行 | 使用该版本兼容接口与环境执行能力 | srt 包装固定本地命令 |
| 限制出网 | 核对 egress 模式与后端兼容性 | 核对平台与环境网络政策 | 核对网络策略及 CubeEgress 部署 | 配置允许域名与系统限制 |
| 取回报告 | 文件接口导出并校验 | 按文件或执行接口取回并校验 | 按兼容接口或存储路径取回并校验 | 从获准写入的工作目录读取并校验 |
| 完成清理 | 显式销毁并确认 | 查询删除操作完成 | 删除并确认节点与平台状态 | 处理进程退出、清理代理与临时文件 |
表中故意没有把所有行改写成相同方法名：接口风格的差异本身就是学习内容。真实接入时，应核对当前版本的创建、执行、文件、超时、销毁与错误处理契约。
E2B 兼容要拆成清单
“支持 E2B SDK”可以降低应用改动，但不代表每个 SDK 版本、模板格式、网络选项、文件接口、错误码和生命周期动作都完全一致。SPACE 的 ECW 文档还专门定义测试过的兼容范围：本次快照基线为 Python e2b 2.21.1 与 e2b-code-interpreter 2.6.2，不能据此宣称 JavaScript SDK 或所有版本已经验证；CubeSandbox 也有自己的扩展与部署规则。
迁移前写一份最小契约：能否创建和查询？执行输出如何返回？文件大小限制是什么？断流能否恢复？pause 保存了什么？delete 多久可确认？用你实际要用的 SDK 版本运行这些检查。
先不要做性能排行榜
启动耗时可能从收到 API 请求开始，也可能只测 VMM 创建；可能结束于返回 ID，也可能结束于客体里第一条命令完成。预热镜像、预启动 VM、快照恢复和真正冷启动都是不同条件。
建议测量“从应用发起请求，到得到经过校验的 250 报告”的完整耗时，并另外记录创建、就绪、执行、导出与清理。统计中位数和尾部延迟，同时记录错误率、并发、硬件和模板。只有同条件的测量才支持相应比较。
第一次选型可以很朴素
想学本地进程权限，优先读 sandbox-runtime；想从 Docker 走向服务 API，先研究 OpenSandbox；想深入 Firecracker 平台状态机，读 SPACE；想研究 RustVMM/KVM、网络和存储组合，读 CubeSandbox。这是阅读顺序建议，并不表示其他项目不能完成同类任务。