一句话结论
Vercel 发布的 scriptc 将 TypeScript 编译为原生程序，启动速度提升 12 倍，但计算密集型任务性能显著落后。
关键要点
- Vercel Labs 推出采用 Apache 2.0 许可证的实验性编译器 scriptc，可将 TypeScript 转为无 Node/V8 依赖的原生可执行文件。
- 基准测试显示 scriptc 启动中位数为 1.78 毫秒，较 Node 24 的 61.78 毫秒快约 34 倍；内存占用低至 1.9MiB。
- 对于使用 Hono 框架的场景，因需启用 --dynamic 参数导致 62% 代码进入 QuickJS 动态执行，吞吐量降至每秒 1.84 万请求，远低于 Bun 的 7.05 万。
- 开发者反馈在最理想情况下，scriptc 运行速度仍比 Node 24 慢 7.5 倍，冷启动耗时 3.6 毫秒。
- 该工具目前标记为实验性项目，支持 macOS、Linux、Windows 及 WASI Preview 1，通过差分测试保证与 Node 行为一致。
背景与事实
Vercel Labs 在 2026 年 7 月 22 日创建了 scriptc 代码仓库，该项目旨在解决 TypeScript 应用对运行时环境的依赖问题。与传统基于 JS 引擎的方案不同，scriptc 使用真正的 TypeScript 编译器进行解析和类型检查，将程序转换为类型化中间表示，最终生成 C 代码、LLVM IR、汇编代码、目标文件、原生可执行文件或 WebAssembly。截至信息发布时间，该仓库已累积约 4900 个 Star，安装方式需 Node.js 24 或更高版本，可通过 npm install -g scriptc 获取。
scriptc 的核心设计将语法结构划分为三个处理层级。默认情况下，代码进行静态编译；对于 npm 软件包和 any 类型代码，在传入 --dynamic 参数时，由一个约 620KB 的内嵌 quickjs-ng 引擎动态执行；若无法处理，编译器将拒绝并返回 SC 错误码及改写建议。这种混合策略试图在性能与兼容性之间寻找平衡，但测试数据显示其局限性明显。一项对比 scriptc 0.0.16、Bun 1.3.12 和 Node 24.18.0 的基准测试揭示，虽然 scriptc 在启动时间和内存占用上具有数量级优势（例如 node:http 服务器空闲时仅占 1.9MiB 内存），但在处理框架代码时，动态执行机制导致性能急剧下降。
在 Hacker News 社区的讨论中，多位开发者分享了实测数据与观点。一名开发者报告称，即使在字节数组这一最理想场景下，scriptc 的运行速度仍比 Node 24 慢 7.5 倍；其生成的 370KB 单一可执行文件虽无运行时依赖，但性能代价高昂。Filip Pizlo 指出，scriptc 将所有数字表示为浮点数并暂缓实现整数类型推断，相当于跳过了“让 JavaScript 跑得快”这一问题的一半；此外，依赖 QuickJS 处理常见的 any 类型代码，形成了动态执行孤岛，不利于性能优化。Simon Willison 则关注其编码效率，指出编码智能体在短短一周内提交了 91.8 万行代码，无需编写 C 或 Rust 即可构建二进制文件具备价值。
实际可用性方面，开发者反馈在本地项目进行兼容性覆盖检查时，几乎每个项目都会产生数百个错误，基本无法直接使用现有代码库。有评论者质疑，若能从头编写无第三方依赖的项目，使用 Rust、Go、Zig 等原生编译语言可能更高效。维护性也是担忧焦点，类似 Vercel 此前发布的 zerolang 在项目发布数周后便停止更新。不过，Remo Jansen 测试发现 scriptc 的冷启动时间为 3.6 毫秒（Node 为 48.9 毫秒），但在计算任务中耗时达 2.33 秒。技术细节上，scriptc 存在若干行为差异：字符串以 UTF-8 存储、内存使用引用计数而非垃圾回收、Object.keys 按声明顺序返回、process.argv[0] 值为 "scriptc"。项目通过差分测试逐字节比较与 Node 的标准输出、标准错误和退出码，确保行为一致性，相关文档位于 scriptc.dev。
影响分析
对于中文开发者与从业者而言，scriptc 的出现改变了 TypeScript 交付形态的思考维度。一方面，其极小的体积（370KB 可执行文件）和零依赖特性，为服务端轻量级部署、边缘计算场景提供了新的技术选项，尤其适合对启动速度敏感但计算负载低的 CLI 工具或微服务。另一方面，7.5 倍的性能差距意味着在主流 Web 服务、数据处理等高负载场景中，直接替换现有 Node.js 或 Bun 方案并不现实。开发者需要权衡：若应用逻辑简单、依赖固定，scriptc 带来的内存和启动优势可能转化为成本节约；但涉及复杂框架（如 Hono）或大量动态类型代码时，性能瓶颈将抵消甚至超过这些优势。此外，由于项目处于实验性阶段且行为差异较多（如内存管理、字符串编码），生产环境引入需承担较高的调试与维护成本。建议团队先在小规模、非关键路径的服务上试点，评估错误率与性能衰减，而非全面迁移。
适用边界
scriptc 的结论在以下条件下不成立或需注意：当应用深度依赖动态类型（any）、复杂 npm 生态或流行 Web 框架时，其性能优势大幅缩水，吞吐量可能低于传统运行时 70% 以上。此外，对于需要长期维护、频繁更新依赖的项目，实验性状态和行为差异（如 Object.keys 顺序、内存模型）可能引入隐蔽兼容性问题。在计算密集型任务（如加密、大数据处理）中，scriptc 的 2.33 秒耗时（对比 Node 的毫秒级）使其不具备竞争力。相反，在启动延迟敏感、逻辑静态、依赖封闭的 CLI 工具或边缘节点场景，其优势显著。
孤本观察
基于来源事实可判断，scriptc 的价值不在替代主流运行时，而在于填补“纯静态编译 TypeScript 为原生二进制”的技术空白；其 620KB 内嵌 QuickJS 引擎的设计，暴露了静态编译与动态类型语言本质间的结构性张力。
常见问题
scriptc 的启动中位数是多少？相比 Node 24 快多少倍？
scriptc 启动中位数为 1.78 毫秒，较 Node 24 的 61.78 毫秒快约 34 倍。
使用 Hono 框架时，scriptc 的吞吐量是多少？与 Bun 相比如何？
使用 Hono 框架时，scriptc 吞吐量降至每秒 1.84 万请求，远低于 Bun 的 7.05 万。
scriptc 支持哪些操作系统？
支持 macOS、Linux、Windows 及 WASI Preview 1。
scriptc 的安装前提条件是什么？
需 Node.js 24 或更高版本，通过 npm install -g scriptc 获取。
scriptc 在计算密集型任务中的表现如何？
冷启动耗时 3.6 毫秒，但在计算任务中耗时达 2.33 秒，比 Node 24 慢 7.5 倍。
来源：InfoQ 中文 AI