Bun v1.3.14：一口气塞进六项硬功能，然后说要重写 Rust

2026年5月13日，Bun 团队丢出 v1.3.14。这不是一个你扫一眼 changelog 就能关掉的版本——内置图像处理、HTTP/3 原生支持、全局虚拟存储安装、Windows ConPTY 终端模拟、FreeBSD 与 Android 原级构建，六项功能同时落地，每一项都在回答开发者拖了多年的老问题。但真正让社区炸开的，是创始人 Jarred Sumner 在 X 上抛出的另一件事：Bun 正在实验性地用 Rust 重写核心路径。

一个以"极致快"为卖点的 JavaScript 运行时，要把自己用 Zig 写的心脏换成 Rust——这到底是务实演进，还是方向性赌博？

六项功能：不是补丁，是集体跳级

先看 v1.3.14 到底塞了什么。

内置图像处理——不再需要 Sharp 或 libvips 的 Node 绑定，Bun 直接在运行时层面提供 resize、crop、format convert。对前端构建链和图片服务场景来说，这意味着少装一个重型依赖、少处理一层 C++ 编译地狱。

HTTP/3 原生支持——QUIC 协议栈直接内置，不需要外部模块或 nginx 前置。对低延迟 API 和移动端场景，0-RTT 连接建立是实打实的性能收益。

全局虚拟存储安装——bun install 现在可以把包挂载到全局虚拟存储，项目间共享硬链接，磁盘占用和安装时间同时下降。这和 pnpm 的内容寻址存储思路一致，但集成在运行时内部，不需要额外配置。

Windows ConPTY 终端模拟——Windows 上的终端体验一直是 Bun 的短板，ConPTY 支持意味着交互式命令、彩色输出、watch 模式终于不再残废。

FreeBSD 与 Android 原生构建——服务器运维和移动端开发各拿一个新平台，Bun 的覆盖面从 macOS/Linux/Windows 扩展到五个。

一口气推六个，节奏激进。但激进本身不是问题——问题是这些功能是否足够稳定，以及它们背后有没有统一的技术主线。

Rust 重写：换心脏还是换皮肤？

Jarred Sumner 提到的 Rust 重写实验，目前信息还比较有限，但核心问题已经很清晰：

Bun 最初选择 Zig，理由是"比 C 更安全的底层语言，同时保持极致的编译速度和运行时性能"。Zig 确实帮 Bun 在早期跑出了惊艳的 benchmark。但三年下来，Zig 的生态短板越来越明显——工具链成熟度、第三方库覆盖、社区人才储备，都和 Rust 不在一个量级。

Rust 重写的吸引力在于：

• 生态杠杆：tokio、hyper、quiche 等 Rust 库已经过大规模生产验证，HTTP/3、异步 IO、TLS 等模块不需要从零造轮子。
• 人才池：Rust 开发者远比 Zig 开发者多，招人、协作、代码审查都更容易。
• 安全性叙事：内存安全在 AI 运行时场景下越来越重要——模型加载、张量操作、沙箱执行，每一个都是潜在的安全边界。

但代价同样硬：

• 编译速度：Rust 的编译时间远长于 Zig，对"快速迭代、快速发布"的开发节奏是直接打击。
• 运行时开销：Rust 的安全检查在编译期完成，运行时零开销——但 async Rust 的 Pin/Send 机制、trait object 动态分发，在极端性能场景下并不总是零成本。
• 项目风险：重写核心路径是工程上最危险的操作之一。不是"能不能写出来"的问题，而是"能不能在保持兼容性的前提下逐步替换"的问题。Node.js 当年用 libuv 替换 libev 是渐进式的；Bun 如果选择大块替换，回归风险极高。

一个可能的路径是：新模块（HTTP/3、图像处理等）用 Rust 写，旧模块（JS 解释器、bundler 等）保留 Zig，通过 FFI 桥接。这避免了全量重写，但引入了双语言维护成本。

实操：用 v1.3.14 跑一个 HTTP/3 + 图片处理的小服务

下面用一个可运行的示例，把 v1.3.14 的两个新功能串起来：启动一个 HTTP/3 服务器，接收上传图片，就地 resize 后返回。

# 先确认版本
bun --version
# 应输出 1.3.14 或更高

# 创建项目目录
mkdir bun-h3-image && cd bun-h3-image

// server.ts — HTTP/3 图片 resize 服务
const PORT = 3000;

Bun.serve({
  port: PORT,
  // v1.3.14: http3 选项启用 QUIC
  http3: true,

  async fetch(req) {
    const url = new URL(req.url);

    // 路由：上传并 resize
    if (url.pathname === "/resize" && req.method === "POST") {
      const formData = await req.formData();
      const file = formData.get("image") as File;

      if (!file) {
        return new Response("缺少 image 字段", { status: 400 });
      }

      // v1.3.14: 内置图像处理，无需 Sharp
      const resized = await Bun.sharp(file)
        .resize(800, 600, { fit: "inside" })
        .webp({ quality: 80 })
        .toBuffer();

      return new Response(resized, {
        headers: {
          "Content-Type": "image/webp",
          "X-Original-Size": String(file.size),
          "X-Resized-Size": String(resized.byteLength),
        },
      });
    }

    // 路由：健康检查
    if (url.pathname === "/health") {
      return Response.json({
        status: "ok",
        http3: true,
        version: Bun.version,
      });
    }

    return new Response("Not Found", { status: 404 });
  },
});

console.log(`HTTP/3 服务运行在 https://localhost:${PORT}`);
console.log(`上传图片: curl --http3 -F "image=@photo.jpg" https://localhost:${PORT}/resize`);

注意：Bun.sharp API 名称和参数以 v1.3.14 实际文档为准，上面是合理推断的用法。如果正式 API 有差异，请查阅 bun.sh/docs 替换对应调用。HTTP/3 需要 TLS 证书，本地测试可用 mkcert 生成：

# 本地生成 TLS 证书（HTTP/3 强制要求）
mkcert -install
mkcert localhost

# 启动服务时 Bun 会自动检测 localhost.pem / localhost-key.pem
bun run server.ts

# 用 curl 测试 HTTP/3 上传（需要 curl >= 7.88 支持 --http3）
curl --http3 -F "image=@test.jpg" https://localhost:3000/resize -o resized.webp

# 健康检查
curl --http3 https://localhost:3000/health

这个示例把两个新功能压在一个进程里，没有外部依赖，没有 nginx，没有 Sharp 编译——这正是 Bun 想卖的故事。

全局虚拟存储：磁盘和时间的双重节省

v1.3.14 的全局虚拟存储安装，用法很简单：

# 启用全局虚拟存储（一次配置，所有项目生效）
bun config set globalVirtualStorage true

# 正常安装——包会硬链接到全局存储，不重复拷贝
cd /path/to/project-a
bun install

cd /path/to/project-b
bun install  # 相同版本的包直接硬链接，秒级完成

效果和 pnpm 的 node_modules/.pnpm 存储类似，但不需要额外安装 pnpm 或配置 .npmrc。对 monorepo 和 CI 环境尤其明显——十个项目共享同一份 lodash，磁盘占用从 10× 降到 1×。

隐忧：快不是唯一的度量

Bun 的叙事一直是"快"。启动快、安装快、跑 benchmark 快。v1.3.14 继续强化这个叙事——HTTP/3 的 0-RTT、图像处理的零依赖、虚拟存储的硬链接，每一项都在说"别等了，用 Bun"。

但"快"掩盖了几个深层问题：

1. 稳定性债务。六项功能同时上线，每一项都需要在不同 OS、不同 Node 版本兼容层、不同负载模式下反复验证。Bun 团队的规模不大，同时维护这么多新路径，回归测试的覆盖率是否足够？社区已经多次报告 Bun 在边缘场景下的崩溃和兼容性问题，激进迭代只会放大这个风险。

2. 双语言维护。如果 Rust 重写推进，Bun 将同时维护 Zig 和 Rust 两条底层实现。FFI 桥接层的调试、性能调优、安全审计，都是单语言项目不需要面对的额外成本。这不是"加一个语言"的问题，是"加一个完整的工程体系"的问题。

3. AI 运行时的定位模糊。标题提到"AI 时代运行时"，但 v1.3.14 的功能列表里没有一项直接服务于 AI——没有 ONNX Runtime 集成，没有 GPU 调度，没有模型沙箱。图像处理可以服务于推理管道的前处理，但那只是间接收益。Bun 如果要走 AI 运行时路线，需要更明确的技术锚点，而不是靠"快"来泛化。

4. 社区信任的节奏。开发者选择运行时，看重的是"我能放心用多久"。Node.js 用了十年建立这个信任；Deno 用了三年还在积累。Bun 的激进节奏在吸引眼球的同时，也在消耗"稳定可依赖"的信号。每一次大版本跳级，都在暗示"上一版还没坐稳，下一版已经来了"。

选择建议：什么时候用，什么时候等

如果你在评估 Bun v1.3.14，可以按场景分层：

Bun 的 v1.3.14 是一次让人兴奋的发布，也是一次需要冷静审视的发布。六项功能落地是实力证明，Rust 重写实验是方向信号——但实力和方向之间，还缺一块叫"稳定性"的桥。这块桥什么时候修好，决定了 Bun 从"快"走向"可靠"的速度。