最近在社区里看到一个很有意思的讨论既然 TypeScript 最终要编译成 JavaScript 在 Node.js 上运行那能不能跳过 JavaScript 和 Node.js 运行时直接把 TypeScript 编译成原生机器码这个想法听起来有点“离经叛道”毕竟 Node.js 的生态和 V8 引擎的性能优化已经深入人心。但仔细一想这背后其实指向了一个更深层的问题我们对于“运行时”的依赖是否在某种程度上成为了性能与部署效率的天花板我花了些时间实际测试了几个声称能将 TypeScript或 JavaScript编译为原生二进制文件的工具和方案。这个过程远比想象中复杂它不是一个简单的“编译开关”而是一连串关于工具链选择、依赖处理、性能权衡和适用边界的决策。如果你也好奇“抛弃 Node.js 运行时”究竟意味着什么是性能的飞跃还是无尽的坑那么接下来的内容或许能给你一个更落地的参考。1. 为什么有人想“绕过”Node.js先理清真实诉求在讨论具体工具之前我们必须先回答一个根本问题为什么要绕开 Node.js这通常不是对 Node.js 本身的否定而是项目发展到特定阶段后遇到了一些绕不开的瓶颈。1.1 冷启动与资源开销Serverless 与 CLI 工具的切肤之痛Node.js 应用启动时需要加载 V8 引擎、初始化运行时、解析你的 JavaScript 代码、进行 JIT 编译然后才能开始执行。对于长期运行的服务端应用这个开销可以忽略不计。但在两个场景下它变得非常突出Serverless 函数FaaS每次函数调用都可能是一个全新的、隔离的容器环境。冷启动时间直接影响到用户体验和响应延迟。一个复杂的 Node.js 应用冷启动可能需要几百毫秒甚至上秒而一个纯粹的原生二进制文件可能只需要几毫秒完成加载和执行。命令行工具CLI用户希望your-cli-tool这个命令能够瞬间响应。如果每次调用都要先启动一个完整的 Node.js 进程解析一堆node_modules里的模块体验会非常糟糕。这也是为什么很多成功的 Node.js CLI 工具如pkg、nexe致力于将应用打包成单一可执行文件的原因——它们本质上是在打包 Node.js 运行时和你的代码但启动时依然需要初始化 V8。绕过 Node.js 运行时直接编译为机器码理论上可以消除这部分运行时初始化开销实现真正的“瞬时启动”。1.2 部署与分发复杂度“node_modules 黑洞”与跨平台兼容“It works on my machine.” 这句调侃背后是 Node.js 项目部署时依赖管理的经典难题。一个项目动辄几百 MB 的node_modules以及潜在的本地二进制模块node-gyp编译问题让部署和分发变得沉重。将应用编译为单个静态链接的原生二进制文件意味着依赖打包所有必要的库包括 C/C 扩展都被静态链接到最终的可执行文件中。无需目标环境安装 Node.js用户不需要关心 Node.js 版本、npm或yarn。简化部署物从一堆文件和文件夹变成一个可直接执行的二进制文件。这对于需要交付给终端用户、嵌入到其他系统或运行在严格控制的环境如某些容器或边缘设备中的应用吸引力巨大。1.3 极致性能与资源控制当 JavaScript 的“动态”成为负担V8 引擎非常强大但其 JIT 编译、垃圾回收GC机制是为了通用 JavaScript 场景设计的。对于一些计算密集型、对内存和 CPU 周期极其敏感的任务如高性能算法、实时数据处理JavaScript 的动态类型和 GC 暂停可能成为瓶颈。原生机器码允许开发者进行更底层的优化和控制例如确定性的内存管理避免 GC 带来的不可预测暂停。更优的 CPU 指令集利用编译器可以进行更激进的静态优化。更小的内存占用去掉了完整的 JavaScript 运行时环境。当然99% 的 Web 服务、业务系统并不需要走到这一步。但存在这样一小部分场景它们构成了探索“TypeScript 到原生”技术的核心驱动力。2. 实测路线图从“打包”到“编译”的频谱目前并没有一个官方的、完美的“tsc --target native”命令。社区的努力分散在几个不同的方向上我们可以把它们看作一个从“轻度包装”到“深度编译”的频谱。2.1 路线一将 Node.js 运行时与你的代码打包pkg, nexe这是最成熟、最接近现有工作流的方案。代表工具有pkg和nexe。原理它们将一个 Node.js 运行时可执行文件和你的应用程序代码包括node_modules打包成一个单独的可执行文件。运行时和你的代码是分离的启动时内置的 Node.js 运行时加载并执行你的代码。体验使用非常方便通常只需一条命令pkg .或nexe app.js。对大多数纯 JavaScript 模块兼容性好。本质这不是编译为原生机器码而是打包。你得到的依然是一个嵌入了 Node.js 的可执行文件冷启动依然需要初始化 V8。优点生态兼容性极佳基本无需修改代码。解决了分发问题单个文件无需安装 Node.js。缺点没有解决冷启动和极致性能问题。文件体积较大因为包含了整个 Node.js 运行时。对原生模块C addons的支持可能比较棘手。# 使用 pkg 的典型流程 npm install -g pkg pkg . --targets node18-linux-x64,node18-win-x64,node18-macos-x64 # 生成三个平台的可执行文件注意如果你只是想简化分发让用户无需安装 Node.js 就能运行你的工具pkg/nexe是目前最稳妥、破坏性最小的选择。它没有改变代码的执行方式。2.2 路线二使用 JavaScript 引擎的 AOT 编译模式Hermes, QuickJS一些 JavaScript 引擎提供了提前编译AOT模式可以将 JavaScript 字节码预编译并打包。HermesFacebook 为 React Native 开发的引擎主打高性能和低内存占用。它可以将 JavaScript 编译为字节码文件运行时直接解释执行字节码避免了源码解析和初始编译的开销。QuickJS一个轻量级、可嵌入的 JavaScript 引擎支持将 JavaScript 编译为可执行文件通过链接器将 QuickJS 库和你的代码静态链接。原理将 JS 源码编译为引擎特定的中间表示字节码然后与一个精简的运行时链接。这个运行时比完整的 Node.js 小得多。体验需要将你的代码适配到目标引擎的 API它们通常不支持完整的 Node.js API如fs、http等模块需要自己实现或寻找替代。工具链相对小众。本质算是“编译”到了字节码但运行时依然是一个小的 JavaScript 虚拟机VM并非真正的原生机器码。优点启动速度比完整 Node.js 快内存占用小。Hermes 字节码的加载和执行效率很高。缺点生态割裂。你无法使用npm上的大多数库除非它们不依赖 Node.js 原生 API。需要为很多基础功能重新造轮子。2.3 路线三真正的源码到原生机器码编译Bun.sh, Nectar, 以及各种转译器这是最激进、也是最接近标题“直接编译为原生机器码”的路线。目前主要有几种形态Bun.sh 的bun build --compileBun 本身是一个新的 JavaScript 运行时替代 Node.js。它的--compile标志可以将你的 JavaScript/TypeScript 应用编译成一个独立的原生二进制文件。其底层使用 Bun 自研的 JavaScriptCore 引擎并通过 Zig 语言和 LLVM 工具链进行编译和链接。bun build --compile ./index.ts --outfile myapp ./myapp # 直接运行编译后的二进制文件体验对 Bun 原生 API 和一部分 Node.js API 兼容性很好速度极快。但它是与 Bun 运行时深度绑定的可以理解为将 Bun 运行时和你的代码一起编译了。将 TypeScript/JavaScript 转译为其他语言再编译这是一条更通用的路径。例如AssemblyScript将 TypeScript 的一个子集编译为 WebAssembly。WASM 可以在任何支持它的运行时包括浏览器、Node.js、Bun、Deno中以接近原生的速度执行但它本身不是独立的可执行文件需要宿主环境。Nectar (由 Perry 等人开发)这是一个新兴的、更前沿的探索。它旨在将 JavaScript/TypeScript 直接编译为高效的、无 GC 的本地代码。其原理可能是进行深度的静态分析和类型推导将 JS 代码转译为 C、C 或 Rust 等系统级语言再利用这些语言的成熟编译器GCC, Clang, Rustc生成高质量机器码。这类项目通常处于非常早期的阶段对语言特性的支持有限生态兼容性几乎是零。原理通过静态分析、类型推导和代码转换将高级的、动态的 JavaScript/TypeScript 语义映射到底层的、静态的系统编程语言或中间表示最终由后端编译器生成机器码。体验挑战巨大。JavaScript 的动态特性如eval、with、动态属性访问、原型链很难在静态编译中完美实现。这类工具通常只支持语言的一个严格子集。本质是真正的“编译”去掉了传统的 JavaScript 运行时代码以机器指令直接执行。优点潜力巨大。理论上可以获得最佳启动性能、最小内存开销和最高执行效率。缺点极不成熟。语言特性支持残缺无法使用现有 NPM 生态调试困难工具链复杂。目前基本处于实验和特定领域如对性能有极端要求的计算模块探索阶段。3. 核心挑战当我们谈论“编译 TypeScript”时到底在编译什么理想很丰满但现实是将 TypeScript/JavaScript 编译为高效原生代码面临一系列根本性挑战。3.1 动态类型与运行时行为JavaScript 是动态类型语言类型在运行时才能确定。很多模式在静态编译时无法分析。function process(obj: any) { return obj.someProperty 10; // someProperty 的类型和存在性在编译时未知 }一个原生编译器必须要么生成包含类型检查的保守代码性能损失。要求开发者使用严格的、可推导的类型子集如 AssemblyScript。引入一个轻量级的运行时来处理动态分发又回到了运行时。3.2 庞大的标准库与生态系统依赖Node.js 不仅仅是一个引擎它提供了fs、net、http、crypto等核心模块以及通过process、Buffer等提供的系统接口。一个“原生编译”方案必须重新实现这些 API用目标系统语言如 C、Rust实现等价功能。这是一个浩大的工程。处理 NPM 模块绝大多数 NPM 模块都直接或间接依赖 Node.js API。编译方案要么放弃整个生态要么提供一个兼容层这又引入了复杂性和开销。3.3 垃圾回收GC的内存管理JavaScript 使用自动垃圾回收。原生系统语言通常使用手动内存管理或所有权系统如 Rust。如何将前者的内存模型安全、高效地映射到后者是一个核心难题。不安全的映射会导致内存泄漏或崩溃。3.4 调试与开发者体验console.log调试在原生二进制文件中如何工作如何获取有意义的堆栈跟踪如何与现有的调试器如 VSCode集成这些开发者体验问题在早期编译器中往往被忽略但却是生产力杀手。4. 实践建议如何根据你的场景做选择面对这些方案不要盲目追求“最原生”。正确的选择取决于你的核心目标。你的主要目标推荐方案关键考量简化分发用户免装 Node.jspkg / nexe (路线一)成熟稳定生态兼容性最好。接受较大的文件体积和正常的 Node.js 启动时间。提升 CLI 工具启动速度Bun --compile (路线三-1)如果 CLI 主要使用 Bun/Node.js 兼容 API且能接受 Bun 的生态这是目前启动最快的生产级方案之一。为 React Native 应用优化启动与性能Hermes 字节码 (路线二)这是 React Native 的官方推荐和标配针对移动端场景深度优化。嵌入式计算、性能敏感模块AssemblyScript - WASM (路线三-2)将计算密集型部分用 AssemblyScript 编写编译为 WASM在主应用可以是 Node.js中调用。平衡了性能与生态。研究、实验、对启动和内存有极端要求Nectar 等前沿编译器 (路线三-2)做好大量适配、放弃现有生态、应对不稳定的工具链的准备。关注其进展但暂不用于生产。构建通用的高性能服务端应用目前不建议绕开 Node.js/Bun/Deno成熟的运行时提供的调试、监控、生态库的价值远超过可能获得的微小性能提升。优化应首先着眼于代码逻辑、数据库、架构层面。4.1 一个务实的渐进路径如果你确实对“原生编译”感兴趣我建议采用渐进式策略从 CLI 工具或独立微服务开始这些应用边界清晰依赖相对较少是理想的试验田。严格限制语言特性避免使用eval、动态属性名、复杂的原型继承等难以静态分析的特性。剥离核心逻辑尝试将最核心、最性能敏感的算法或模块用 TypeScript 的严格子集或直接使用 Rust/Go编写并编译为原生模块/WASM供主应用调用。这样大部分业务逻辑依然享受 JavaScript 生态的便利。建立完整的测试与基准在切换前后必须进行全面的功能测试和性能基准测试。确保功能正确并量化性能提升是否值得付出的代价。5. 未来展望这不是替代而是扩展“将 TypeScript 编译为原生机器码”这个想法其意义不在于取代Node.js 或 JavaScript 运行时。对于绝大多数 Web 服务、业务应用来说V8 引擎持续的性能进化、Node.js 丰富的生态、以及动态语言带来的开发效率是不可替代的优势。这项探索的真正价值在于扩展JavaScript/TypeScript 的能力边界。它为这门语言开辟了新的应用场景超低延迟的边缘计算函数。资源极度受限的嵌入式设备。需要与系统深度集成的高性能原生插件。追求极致启动速度的客户端工具。它更像是在 JavaScript 生态大厦旁边新建一座专门用于“系统级编程”的侧厅。两者通过清晰的走廊如 WASM连接而不是推倒重建。所以下次当你看到类似“抛弃 Node.js”的标题时不妨先问自己我的项目到底卡在哪个环节是启动慢、部署烦还是计算瓶颈答案很可能不是“抛弃”而是“选择合适的工具”。对于大多数场景优化你的代码、升级 Node.js 版本、使用pkg打包或者尝试 Bun 这样的新运行时才是更直接、更有效的路径。而那些前沿的编译技术让我们看到了另一种可能性它们正在为 JavaScript 世界绘制一幅更广阔的地图。