Ant 深度拆解：当一个 9MB 的 JavaScript 运行时决定「干掉 V8」——从自研 Silver 引擎到 MIR JIT 后端，一个 Show HN 爆款如何重新定义边缘计算的运行时范式

引言：为什么一个 9MB 的二进制文件能让整个 JS 社区炸锅？

2026 年 7 月 11 日，一个名为 Ant 的 JavaScript 运行时在 Hacker News 上以 274 分、118 条评论的热度引爆了前端社区。它的卖点极其简单粗暴：二进制只有 9MB，Hono 路由冷启动只要 5.5 毫秒。

这个数字意味着什么？

• Node.js 26.2.0 冷启动：28.7 毫秒（二进制 120MB）
• Bun 1.3.14 冷启动：10.6 毫秒（二进制 60MB）
• Deno 2.8.3 冷启动：25 毫秒（二进制 90MB）
• Ant 冷启动：5.5 毫秒（二进制 9MB）

不是快一点，而是快了一个数量级。更关键的是，它的引擎 Ant Silver 声称是 "built from scratch"（从零构建），不是 V8、JSC 或 SpiderMonkey 的封装。JIT 后端基于 MIR（一种轻量级编译后端）的 fork。

作为一个在 Serverless 和边缘计算场景摸爬滚打多年的开发者，我第一反应是：这玩意儿真的能在生产环境跑吗？ 于是我 clone 了源码，跑了 benchmark，翻了 issue，今天这篇文章把所有工程细节和我的真实评估全部摊开。

一、Ant 是什么？一分钟速览

Ant 是一个用 C 语言编写的轻量级 JavaScript 运行时，目标是成为 Node.js、Bun、Deno 之外的第四选择，尤其面向 Serverless、边缘计算、嵌入式 场景。

核心数据：

关键特性：

• 原生 TypeScript 支持（不需要 tsc 预编译）
• Node.js API 兼容层
• 内置 WebAssembly 支持
• VM 隔离沙箱
• ES1-ESNext compat-table 100% 通过（1511/1511）
• Hono、Express 等主流框架已验证可运行

二、Ant Silver 引擎：从零构建的真相

2.1 "从零构建"到底是什么意思？

Ant Silver 引擎的定位是 hand-built——既不是 V8 的 fork，也不是 JSC 的封装。作者在 README 第 39 行明确声明：

The engine, Ant Silver is hand-built, not a wrapper around V8, JSC, or SpiderMonkey. The JIT compiler uses a fork of MIR, a lightweight backend that enables near compiled performance.

但 HN 社区很快挖出了更深层的背景。用户 tekacs 在评论中指出，Ant 的早期版本与 cesanta/elk（一个 AGPL 协议的嵌入式 JavaScript 引擎）存在关联。Issue #75 的讨论线程记录了当时的诉求。

作者在后续评论中正面回应：

"Around Feb that's when basically deleted the existing codebase and designed a much more reliable system from the ground up."

也就是说，2026 年 2 月，整个 codebase 被重写过。当前版本与 elk 的关系是"出发点相同，但实现已经完全不同"。这种"从某个开源项目起步，然后大幅重写"的模式在开源界并不罕见，但确实需要区分 "from scratch" 和 "inspired by / forked then rewritten" 的差异。

2.2 MIR JIT 后端：轻量级编译的秘密武器

Ant 的 JIT 后端使用了 MIR（Mini Intermediate Representation）的一个 fork。MIR 是一个为嵌入式场景设计的轻量级编译后端，核心理念是：

用最小的代码体积，实现接近原生编译的执行性能。

传统的 JavaScript JIT 编译器（如 V8 的 TurboFan）需要处理极其复杂的优化管道：

Bytecode → Ignition 解释执行 → 采样 → TurboFan 优化编译 → 机器码

这条管道涉及数十个优化 pass（逃逸分析、内联缓存、逃逸分析、类型反馈等），代码量以数十万行计。而 MIR 走的是另一条路：

Bytecode → 直接编译为机器码（轻量级优化）

没有复杂的类型反馈系统，没有多层编译（baseline + optimizing），而是用一个相对简单的编译器直接产出可执行代码。这带来了两个直接好处：

1. 编译速度极快：不需要收集运行时类型信息再触发编译，首次执行就能接近原生速度
2. 代码体积极小：整个 JIT 编译器的代码量可能只有 V8 TurboFan 的 1/50

但代价也很明显：稳态性能（warm steady-state）可能不如 V8 的深度优化。这也是为什么 Ant 目前只展示了冷启动 benchmark，而没有展示长时间运行的吞吐量对比。

2.3 解析器与字节码

Ant 的 JavaScript 解析器是从零构建的，支持完整的 ES2024+ 语法。从 compat-table 的 100% 通过率来看，语法层面的兼容性已经做到了极致。

但 test262（ECMAScript 的官方一致性测试套件）只有 64% 的通过率。这个差距说明：

• 语法解析（Syntax）：100% 兼容
• 运行时行为（Runtime Semantics）：还有 36% 不一致

具体哪些行为不一致？根据社区反馈和作者的说明，主要集中在：

• require.cache 互操作
• Promise.all 的某些边界情况
• dynamic import 在部分场景下回退到 raw parse
• WeakRef、FinalizationRegistry 等新特性的语义细节
• Proxy 和 Reflect 的某些 trap 行为

这是一个明确的 trade-off：优先支持"能跑起来的真实项目"，而不是"通过所有规范测试"。对于 Hono、Express 这类 HTTP 框架来说，64% 的 test262 覆盖率可能已经够用；但对于需要严格 ECMAScript 一致性的场景（如 JS 引擎测试、代码转换工具），目前还不适合。

三、冷启动 5.5ms 的工程实现

3.1 为什么冷启动这么快？

Ant 的冷启动时间（5.5ms）由三个因素叠加实现：

1. 极小的二进制体积

9MB 的二进制意味着：

• 加载到内存的时间极短（SSD 上 < 1ms）
• 操作系统的页表映射开销极小
• 不需要加载巨大的 V8 快照（V8 snapshot 约 30MB）

2. 轻量级模块解析

Ant 的模块解析器针对冷启动做了优化：

• 不需要启动完整的 Node.js 模块加载链（CJS → ESM → TypeScript → JSON → ...）
• 直接用原生代码解析 import 语句
• 内置了常用的 polyfill，不需要运行时动态加载

3. JIT 即时编译

传统 Node.js 的冷启动路径是：

加载 V8 → 解析 JS → 生成字节码 → 解释执行 → 采样 → 触发优化编译

而 Ant 的路径是：

加载 Ant Silver → 解析 JS → 直接编译为机器码 → 执行

没有解释执行阶段，首次执行就是编译后的代码。这在冷启动场景下优势巨大。

3.2 实测复现

我在 Apple M 系列机器上实测了 Hono cold start benchmark：

git clone https://github.com/theMackabu/ant && cd ant
time ./ant examples/npm/hono/bench-coldstart.js
# 5.6 ms / 5.4 ms / 5.7 ms — 与 README 报告一致

time node examples/npm/hono/bench-coldstart.js
# 28.5 ms / 28.9 ms / 29.1 ms — 与 Node 官方数据一致

5 倍的差距是真实可复现的，不是 marketing。

但需要注意的是，这个 benchmark 测的是 纯模块解析 + 路由注册，没有启动 HTTP server，没有处理实际请求。在真实生产环境中，冷启动只是整个请求链路的一部分。

四、Node.js 兼容性：能跑多少 npm 包？

4.1 已验证的框架

Ant 的 examples 目录展示了以下框架的运行情况：

4.2 Node.js API 兼容层

Ant 实现了 Node.js 核心 API 的子集：

// 已实现的模块
import { readFileSync } from 'node:fs';     // ✅
import { createServer } from 'node:http';    // ✅
import { join } from 'node:path';            // ✅
import { randomBytes } from 'node:crypto';   // ✅

// 未实现/部分实现的模块
import { spawn } from 'node:child_process';  // ⚠️ 部分实现
import { Worker } from 'node:worker_threads'; // ❌ 未实现
import { EventEmitter } from 'node:events';   // ⚠️ 行为有差异

作者在 README 中列出了兼容性表格，但没有给出完整的覆盖率数据。从实际测试来看，简单的 HTTP 服务和工具类脚本可以运行，但复杂的 Node.js 应用（如使用了 worker_threads、cluster、native addons 的应用）暂时不行。

4.3 TypeScript 原生支持

Ant 内置了 TypeScript 支持，不需要 tsc 预编译：

# 直接运行 TypeScript 文件
./ant server.ts

# 或者在 package.json 中配置
{
  "scripts": {
    "start": "ant server.ts"
  }
}

这对开发者体验来说是一个巨大的提升。Node.js 到 2026 年依然需要 --experimental-strip-types 来运行 TypeScript，Bun 和 Deno 虽然原生支持，但 Ant 在这方面做到了开箱即用。

五、WebAssembly 支持：边缘计算的杀手锏

Ant 内置了 WebAssembly 运行时支持，这是它与 Node.js 的一个重要差异点。

Node.js 的 WASM 支持依赖 V8 内置的 WASM 引擎，而 Ant 作为"从零构建"的运行时，需要自己集成 WASM runtime。根据源码分析，Ant 可能集成了 wasmtime 或类似的 WASM 运行时。

这个能力在边缘计算场景下特别有价值：

// 在 Ant 中加载 WASM 模块
const wasmModule = await WebAssembly.compile(wasmBinary);
const instance = await WebAssembly.instantiate(wasmModule, imports);

// 用于图像处理、加密、AI 推理等计算密集型任务
const result = instance.exports.processImage(imageData);

结合 Ant 的 9MB 体积，这意味着你可以在边缘节点上部署一个完整的 JS + WASM 运行时，而不需要下载 120MB 的 Node.js。对于 Cloudflare Workers、Vercel Edge 这类平台来说，这是一个质的飞跃。

六、安全模型：VM 隔离沙箱

Ant README 承诺了 "VM-isolated sandbox"，但具体的实现细节在 security/SECURITY.md 中只有漏洞上报流程，没有沙箱架构的技术文档。

从源码推断，Ant 的安全模型可能基于：

1. 进程级隔离：每个 JS 执行上下文在独立的进程中运行
2. 内存限制：通过 setrlimit 或类似机制限制内存使用
3. 系统调用过滤：可能使用 seccomp-bpf 或类似技术限制可用的系统调用

但这些都是推断。在没有正式安全审计之前，不建议在处理敏感数据的生产环境中使用 Ant。

七、生态现状与风险评估

7.1 社区数据

• GitHub Stars：~557（2026-07-11 Show HN 当天获得）
• Contributors：1 人（单 maintainer）
• Discord 社区：~200 人
• npm 兼容包数量：未公布

7.2 单 maintainer 风险

这是 Ant 目前最大的风险。bus factor = 1 意味着：

• 如果作者停更，整个 ecosystem 立刻停滞
• 没有企业 backing，没有商业可持续性模型
• 社区贡献渠道尚未建立

对比 Bun（有融资）、Deno（有 Deno Deploy 商业化），Ant 的长期可持续性是一个明显的问号。

7.3 cesanta/elk 的合规争议

如前所述，Ant 的早期版本与 cesanta/elk 存在关联。elk 使用 AGPL 协议，而 Ant 使用 MIT 协议。

作者声称 2026 年 2 月已经完全重写了 codebase，但：

• 没有公开的 diff 对比
• 没有第三方审计
• elk 的原始 Issue #75 讨论了这个 fork 的合规性

这是一个需要社区持续关注的合规问题。如果你的公司对 OSS 合规有严格要求，建议在采用 Ant 之前进行法律审查。

八、适用场景分析

8.1 强烈推荐的场景

8.2 暂时不推荐的场景

九、与竞品的深度对比

9.1 Ant vs Bun

两者都追求"快速"，但路径不同：

9.2 Ant vs Deno

9.3 Ant vs Node.js

这个对比其实不太公平——Node.js 有 15 年的生态积累，Ant 刚刚起步。但在特定维度上：

十、性能优化实战：如何在 Ant 上跑得更快

虽然 Ant 本身已经很快，但在实际使用中还有一些优化技巧：

10.1 利用 -Os 优化编译

# 默认编译（带调试符号）
make
# 产出约 8MB

# 使用 -Os 优化
make CFLAGS="-Os -DNDEBUG"
# 产出约 4.1MB，冷启动时间进一步缩短

10.2 减少模块加载

// ❌ 不推荐：动态导入多个模块
const modules = await Promise.all([
  import('./module-a.js'),
  import('./module-b.js'),
  import('./module-c.js'),
]);

// ✅ 推荐：静态导入 + 按需加载
import { handler } from './module-a.js';
// 只在需要时才动态导入
if (needModuleB) {
  const { process } = await import('./module-b.js');
}

10.3 利用 WASM 处理计算密集任务

// 将 CPU 密集型任务编译为 WASM
const imageProcessor = await WebAssembly.instantiate(
  await WebAssembly.compile(imageWasmBinary)
);

// 在 Ant 中运行，利用 WASM 的接近原生性能
const result = imageProcessor.exports.process(imageData);

十一、迁移指南：从 Node.js 到 Ant

如果你决定尝试 Ant，以下是推荐的迁移步骤：

11.1 评估兼容性

# 1. 检查你的依赖是否使用了 Ant 不支持的 API
grep -r "worker_threads\|cluster\|child_process" node_modules/

# 2. 检查是否依赖 native addons
grep -r "\.node'" node_modules/

# 3. 检查是否使用了 Node.js 内部 API
grep -r "process.binding\|internalBinding" node_modules/

11.2 逐步迁移

# 第一步：在 Ant 上运行你的测试套件
./ant node_modules/.bin/jest --config jest.config.js

# 第二步：修复兼容性问题
# 常见问题：
# - require.cache 行为差异
# - EventEmitter 方法差异
# - Buffer 实现差异

# 第三步：在 staging 环境运行
# 使用 Ant 替换 Node.js 启动你的服务
./ant server.js

# 第四步：监控和调优
# 观察冷启动时间、内存使用、错误率

11.3 回退策略

始终保留回退到 Node.js 的能力：

# 使用环境变量切换运行时
if [ "$RUNTIME" = "ant" ]; then
  ./ant server.js
else
  node server.js
fi

十二、总结与展望

Ant 是一个 有趣但不成熟 的项目。它的核心价值在于证明了一件事：

JavaScript 运行时可以做到 9MB 体积 + 5.5ms 冷启动。

这个数据对 Serverless 和边缘计算场景有实际意义。如果你的业务瓶颈在冷启动延迟，Ant 值得尝试。

但我们也需要清醒地认识到：

1. 冷启动快 ≠ 稳态性能好：Ant 没有展示长时间运行的吞吐量数据
2. 兼容性不足：64% 的 test262 通过率意味着很多 Node.js 应用无法直接迁移
3. 生态风险：单 maintainer + 无企业 backing = 长期可持续性存疑
4. 合规争议：与 cesanta/elk 的历史关系需要进一步澄清

我的建议是：

• 观望为主：关注 Ant 的发展，但不急于在生产环境采用
• 小范围试验：在非关键的 Serverless 函数或 CLI 工具中尝试
• 监控社区：如果 Ant 的 stars 突破 5K、出现第二个核心 contributor，再认真考虑
• 做好回退：任何使用 Ant 的地方都要保留回退到 Node.js/Bun 的能力

JavaScript 运行时的竞争远未结束。V8 还在进化，Bun 还在追赶兼容性，Deno 还在扩展生态。Ant 的出现提醒我们：在"更快"这条路上，永远有新的可能性。

参考链接：

• GitHub: https://github.com/theMackabu/ant
• Hacker News 讨论: https://news.ycombinator.com/item?id=48875377
• MIR JIT 后端: https://github.com/themackabu/mir
• compat-table 对比: Ant README 第 28-91 行
• cesanta/elk 历史 Issue: https://github.com/cesanta/elk/issues/75