一个 100MB 的 CLI 二进制文件

Anthropic 刚刚宣布 Claude Code 现在可以作为原生构建使用。翻译一下：这是一个可以通过 curl 安装的二进制可执行文件，不需要 Node.js。

听起来不错，对吧？一条命令，无依赖，后台自动更新。任何 CLI 工具的梦想。

但有一个细节：二进制文件大小为 100MB。

为了给你一个参考，git 二进制文件大约 3MB。curl 不到 1MB。即使是以生成大二进制文件著称的 Go，也很少超过 15-20MB。

这 100MB 里到底装了什么？

不是 Rust，是穿着可执行文件外衣的 Bun

当我看到这个公告时，我的第一个想法是：“他们用 Rust 重写了一切。“这很有道理，不是吗？如果你想要一个原生的、快速的、无运行时的二进制文件，Rust 是明显的选择。

结果不是这样。

Claude Code 仍然是 TypeScript。他们所做的是使用 bun build --compile 将其打包为可执行文件。

bun build --compile 是如何工作的

这个神奇的命令是：

1

bun build ./src/index.ts --compile --outfile claude

它具体做了什么？三件事：

1. 打包

首先，Bun 充当打包器。它获取你的入口文件（index.ts），解析所有的 import，并生成一个包含所有代码串联的单一 JavaScript 文件。包括你的 node_modules 依赖，解决tree-shaking以消除死代码，并压缩结果。

到这里，与 esbuild 或 webpack 做的没有什么不同。

2. 嵌入

这里是有趣的部分。Bun 获取那个 JavaScript 包，并将其嵌入到可执行文件中，连同完整的 Bun 运行时一起。

生成的可执行文件有这样的结构（简化）：

┌─────────────────────────────────┐
│   Bun 运行时 (~95MB)             │
│   ├── JavaScriptCore 引擎       │
│   ├── 原生 APIs (fs, http)      │
│   ├── Zig 运行时                │
│   └── 静态 libc                 │
├─────────────────────────────────┤
│   你的打包代码 (~5MB)            │
│   └── 压缩的 JavaScript         │
└─────────────────────────────────┘

当你执行二进制文件时，Bun 运行时从自身提取 JavaScript 代码并执行。这就像一个自解压缩文件，但是用于代码。

3. 交叉编译

Bun 可以为其他平台生成二进制文件：

1
2
3

bun build ./src/index.ts --compile --target=bun-linux-x64 --outfile claude-linux
bun build ./src/index.ts --compile --target=bun-darwin-arm64 --outfile claude-mac
bun build ./src/index.ts --compile --target=bun-windows-x64 --outfile claude.exe

你不需要 Linux 来生成 Linux 二进制文件。Bun 包含每个平台的预编译运行时。

JavaScriptCore vs V8

Node.js 使用 V8，Chrome 的 JavaScript 引擎。Bun 使用 JavaScriptCore (JSC)，Safari 的引擎。

为什么重要？因为它们是不同的野兽：

方面V8 (Node)JavaScriptCore (Bun)
启动时间~50ms~5ms
峰值性能非常高高
内存使用更多更少
JIT 层级2 (Ignition → TurboFan)4 (LLInt → Baseline → DFG → FTL)

JSC 启动更快，因为它有更多的 JIT 编译层级。它从很快的解释代码开始（LLInt），然后在执行时在后台进行优化。相反，V8 需要在开始执行之前做更多的初始工作。

对于启动、做某事、然后结束的 CLI，启动时的 45ms 差异很重要。对于运行数小时的服务器，就不那么重要了。

为什么是 Zig（而不是 Rust 或 C++）

Bun 主要用 Zig 编写，用一些 C++ 处理与 JavaScriptCore 交互的部分。

Bun 的创造者 Jarred Sumner 选择 Zig 有几个原因：

  1. 与 C 的互操作性：Zig 可以无开销或 FFI 调用 C 代码。JavaScriptCore 用 C++ 编写，Zig 可以直接与其链接。

  2. 无垃圾收集器的内存控制：像 Rust 一样，但语法更简单，没有让你抓狂的借用检查器。

  3. 简单的交叉编译：Zig 可以从任何平台编译到任何平台。你不需要 Linux 机器来为 Linux 编译。

  4. （相对）小的二进制文件：Zig 中的"Hello World"大约 5KB。Go 中约 2MB。Rust 中约 300KB。

结果是一个启动快、使用内存少、可以作为单一静态二进制文件分发的运行时。正是你需要的。

这不是什么

为了澄清：这不是 AOT（预编译）编译，如 GraalVM 对 Java 或 WASM 所做的那样。

你的 TypeScript 代码不会转换为 CPU 指令。它仍然在运行时被 JavaScriptCore 解释。唯一改变的是解释器与代码一起打包。

这与以下工具使用的技巧相同：

  • Node.js 的 pkg
  • Python 的 PyInstaller
  • Electron 应用的 electron-builder

这不是魔法。这是将运行时和代码放在同一个包中。这就是为什么它重 100MB——大部分是 JavaScriptCore 和 Bun 的 APIs，而不是 Claude Code 的代码。

Anthropic 获得了什么？

这就是关键。因为这个改变不是为了你。

更少的支持工单

你知道 npm 有多少问题吗？权限损坏、缓存损坏、Node 版本冲突、PATH 配置错误、神秘消失的 800MB node_modules…

每一个这样的问题都是一张支持工单。每张支持工单都是金钱和时间。乘以 Claude Code 的数百万用户，你就会明白为什么 Anthropic 决定将 npm 从等式中消除。

无摩擦的自动更新

使用 npm，更新 Claude Code 需要用户执行 npm update -g @anthropic/claude-code。有些人会这样做。很多人不会。

使用原生构建，更新在后台自动进行。Anthropic 完全控制你运行的版本。对于一个快速迭代并不断修复错误的公司来说，这是黄金。

受控环境

当你收到错误报告时，你首先问的是：“你有什么版本的 Node？什么版本的 npm？什么操作系统？“使用原生构建，所有这些都消失了。每个人的执行环境都是相同的。

更容易重现的错误 = 更容易修复的错误。

用户获得了什么？

如果你没有安装 Node.js

明显的改善。以前你需要：

  1. 安装 Node.js
  2. 配置 PATH（如果没有自动完成）
  3. 安装 npm（Node 自带，但有时需要更新）
  4. 执行 npm install -g @anthropic/claude-code
  5. 祈祷没有冲突

现在你需要：

1

curl -fsSL https://claude.ai/install.sh | sh

对于不是开发者的人——产品经理、作家、设计师——差异是巨大的。

如果你已经有 Node.js

说实话，你获得很少。也许你会避免一些 npm 的偶尔问题。自动更新很方便。仅在原生构建中提供的原生语法高亮是一个不错的功能。

但如果你已经让 Claude Code 与 npm 工作，这个改变基本上是横向的。你在日常使用中不会注意到差异。

100MB 的视角

我知道听起来很夸张。100MB 用于一个 CLI。我们的爷爷奶奶用 4KB RAM 编程，而我们在这里下载 100MB 来执行命令。

但让我们实际一点：

  • VS Code 大约 300MB
  • Slack 大约 500MB
  • iOS SDK 大约 30GB
  • 一个中等的 Node.js 项目有 500MB+ 的 node_modules

我最喜欢的：macOS Sequoia 包含 45GB 的壁纸。

四十五千兆字节。壁纸。4K 视频的水母漂浮、海浪破碎和极光，让你的 Mac 有漂亮的屏幕保护程序。是 Claude Code 大小的 450 倍。为了。壁纸。

Claude Code 给你一个可以编写代码、执行命令和管理整个项目的 AI 助手。苹果的壁纸给你…水母。

在 2026 年，有 1Gbps 光纤和标准的 1TB SSD，100MB 是统计噪声。你几秒钟就下载完，保存并忘记。

优雅吗？不。在实践中重要吗？也不。肯定比该死的水母不重要。

你应该迁移吗？

如果你有 npm 版本且工作良好，没有急迫性。你可以通过从 npm 版本执行 claude install 来迁移。

如果你是第一次安装 Claude Code，使用原生构建。这是推荐选项，给你带来最少问题的选项。

如果你是那种因为有 100MB 二进制文件占用空间而烦恼的人，你可以继续使用 npm。Anthropic 说他们将维护两个选项，尽管很明显哪个是未来的方向。

重复的模式

这不是新的。这是我们在软件中一次又一次看到的相同模式：

  1. 你从共享依赖开始（DLLs、系统库、npm 包）
  2. 你遇到兼容性、版本和分发问题
  3. 你最终将所有东西打包在一个简单工作的大块中

Docker 也这样做了。Electron 也这样做了。Bun 正在这样做。

这是最优雅的解决方案吗？不。这是引起最少问题的解决方案吗？几乎总是如此。

有时工程不是找到最美的解决方案，而是产生最少支持工单的解决方案。Anthropic，有着十亿收入和数百万用户，比任何人都更了解这一点。

相关文章：