Bun v1.3.14 更新全解读：内置图像处理、HTTP/3、全局虚拟存储与 fetch HTTP/2 客户端

如果你用 Bun 做服务端、CLI 或者构建工具，大概率已经习惯了它每隔几周就「塞一堆能力进运行时」的节奏。Bun v1.3.14（2026-05-13 发布）这次的版本仍然是这种风格，但密度比平时更高一些：

图像处理不再需要装 sharp
HTTP/3 不再需要 nginx / Caddy 反代
隔离式 link 装包，从「慢一点」变成「快 7 倍」
fetch() 自己长出了 HTTP/2 与 HTTP/3 客户端
还顺带把 JavaScriptCore 跟到了 565 个上游提交

下面按「你为什么应该关心」的顺序，把这次发布拆开讲。

先给结论：v1.3.14 的主线是什么？

Bun 1.3.14 的更新可以归到三条主线：

能力内置化：图像处理（Bun.Image）、HTTP/3 服务、fetch 的 HTTP/2/3 客户端、Windows 上的 Bun.Terminal——都是「原本需要装库才能做」的事，现在变成了运行时自带。
包管理向 isolated linker 倾斜：新增 install.globalStore，让 --linker=isolated 在大型 Monorepo 下的速度，从「比 hoisted 慢一点」直接变成「快一个数量级」。
基础设施持续打磨：fs.watch() 后端重写、JavaScriptCore 升级、跨语言 LTO、ESM 加载更快、二进制体积变小、内存占用下降。

外加几个偏「细节地狱」但很值钱的修复：FormData 多部分边界格式（影响 OpenAI API）、ECH GREASE 导致的 fetch 卡死、MySQL BLOB 在 GC 时被破坏，等等。

1) `Bun.Image`：把 sharp 的 80% 写进运行时

这一项是这次发布里覆盖面最广、感知最直接的能力。

Bun 1.3.14 新增了 Bun.Image —— 一个链式调用的图像处理 API。能力范围：

输入：路径、ArrayBuffer / TypedArray、Blob / BunFile / S3File、data: URL
变换：resize、rotate、flip、flop、modulate
重采样滤镜：nearest、box、bilinear、cubic、mitchell、lanczos2/3、mks2013、mks2021（与 sharp 对齐）
输出：bytes() / buffer() / blob() / toBase64() / dataurl() / placeholder()（thumbhash）/ metadata() / write()
格式：全平台支持 JPEG / PNG / WebP / GIF / BMP；macOS & Windows 额外支持 HEIC / AVIF / TIFF
线程模型：除 metadata() 外都在主线程之外执行

官方示例：

javascript

await Bun.file("photo.jpg")
  .image()
  .resize(1024, 1024, { fit: "inside" })
  .rotate(90)
  .webp({ quality: 85 })
  .write("thumb.webp");

性能对比（vs sharp 0.34.5）：

metadata()：~70× 更快
1080p PNG → 400×400 → JPEG：1.38× 更快
4K JPEG → 1920×1080 → JPEG：1.22× 更快

我的评价是：sharp 仍然是 Node 生态的事实标准，但对「只需要做缩略图 / 格式转换 / 提取元数据」的常见场景来说，Bun.Image 已经能完全替代。最大的现实收益不是性能，而是——

少一个 node-gyp / 原生模块构建链路。

任何在 Docker / 边缘运行时部署过 sharp 的人都会理解这句话的价值。

2) 全局虚拟存储：让 isolated linker 终于「真的快」

bun install --linker=isolated 是 Bun 的「pnpm 风格」装包模式（每个包独立 node_modules、靠符号链接组合）。它的卖点是安全（防幽灵依赖）和磁盘节省，但代价一直是——比 hoisted 模式慢一点。

1.3.14 引入了 install.globalStore 选项，把所有项目共享一个全局虚拟存储池。

基准（Apple Silicon、1400 个包的 fixture）：

Linker 模式	耗时
Hoisted	823ms
Isolated（旧）	841ms
Isolated + globalStore	115ms

clonefileat 系统调用次数：0。

启用方式（bunfig.toml）：

toml

[install]
globalStore = true

或者用环境变量：

bash

BUN_INSTALL_GLOBAL_STORE=1 bun install

为什么这件事重要：

Monorepo 场景：以前选 isolated 是「为了安全付出性能代价」，现在不用选了
CI 缓存：全局存储天然适合做跨任务缓存
磁盘占用：跨项目去重，比每个 repo 自己 node_modules 节省

如果你之前因为「太慢」而没用 isolated linker，这次值得重新评估。

3) Bun.serve 加上 HTTP/3 支持（实验性）

Bun.serve 现在可以直接吐 HTTP/3，由 lsquic v4.6.2 驱动。

javascript

Bun.serve({
  port: 443,
  tls: { cert, key },
  http3: true,
  fetch(req) { return new Response("hi"); },
});

官方给出的吞吐数据（Linux x64）：

场景	HTTPS/1.1	HTTP/3
静态路由	189,130 req/s	509,135 req/s
动态 fetch handler	142,323 req/s	283,485 req/s

但目前还有不少限制，官方明确标注「highly experimental」：

不支持 HTTP/3 上的 WebSocket
0-RTT 暂未启用
不支持 Unix sockets
不支持 trailers
不支持 Expect: 100-continue

我的判断：

生产侧：建议先观望；HTTP/3 的真正瓶颈通常在客户端、CDN、网络中间件，不是源站
场景侧：如果你做的是直连边缘 + 弱网移动客户端（比如 IoT、游戏后端、实时音视频信令），可以提前在 staging 验证

4) `fetch()` 的 HTTP/2 与 HTTP/3 客户端（实验性）

这是这次发布里我个人最期待的能力之一。

Bun 内置 fetch() 一直只跑 HTTP/1.1。1.3.14 同时上了两个实验性客户端：

HTTP/2

开启方式：

bash

# 全局开关
BUN_FEATURE_FLAG_EXPERIMENTAL_HTTP2_CLIENT=1 bun run app.ts
# 或 CLI flag
bun --experimental-http2-fetch app.ts

或者按请求开启：

javascript

const res = await fetch("https://example.com", { protocol: "http2" });

能力清单：

多路复用（multiplexing）
连接复用（coalescing）
keep-alive 池化
请求体流式上传
REFUSED_STREAM / GOAWAY 自动重试
Content-Length 严格校验（RFC 9113 §8.1.1）
Expect: 100-continue
HPACK bomb 防护（256 KiB 上限）
PING 反射防护（1 MiB 上限）

不支持：HTTP 代理 / CONNECT、Unix sockets、server push、明文 HTTP/2（h2c）。

HTTP/3

javascript

const res = await fetch("https://example.com/", { protocol: "http3" });

支持所有 HTTP 方法、重定向、gzip、ReadableStream 上传、全双工流、AbortSignal，以及 Alt-Svc 协商的 HTTP/3 升级（RFC 7838，需要 --experimental-http3-fetch）。

为什么这件事值得关注：

之前在 Bun 里要发 HTTP/2 请求，要么用 Node 兼容层的 node:http2，要么外挂一个 client。现在「fetch() 直接说话」，对调用云厂商 API、对接 gRPC-Web、跨区域回源等场景，是真实的减负。

5) `fs.watch()` 完全重写：Linux / macOS / FreeBSD

fs.watch() 是 Node 生态老大难。Bun 这次直接对接 OS 原生 API：

Linux：inotify
macOS：FSEvents
FreeBSD：kqueue

伴随的修复：

Linux 递归监听：现在能正确捕获「监听期间新建的子目录」
Linux 删后重建：被删后又重建的文件会重新触发 change 事件
macOS 线程：不再为同一个 watcher 拉起两个线程

如果你之前在 dev server、热重载、chokidar 这条链上踩过「watcher 偶尔不触发」的坑，这次升级就是答案。

6) `bun --no-orphans`：进程死了，孩子也别活着

一个看起来很小、但实际很解气的 flag：

bash

bun --no-orphans run my-script

行为：父进程一旦死亡，递归 SIGKILL 所有后代进程。

实现上：

Linux：prctl(PR_SET_PDEATHSIG, SIGKILL)
macOS：kqueue 的 EVFILT_PROC / NOTE_EXIT
用「停 → 验证 → 杀」的策略避免 PID 重用风险

适用场景非常具体但很高频：

本地 dev server 启了 sub-process，但 Ctrl+C 后子进程残留
CI 任务超时被杀，但派生出来的 Playwright / Vite / esbuild 还在跑
容器里跑测试时，僵尸进程拖死整个 pod

以前要靠 tini / dumb-init / 自己写 trap，现在加一个 flag 就行。

7) Windows 上的 `Bun.Terminal`（ConPTY）

Bun.Terminal 之前只在 macOS / Linux 上能用。1.3.14 通过 CreatePseudoConsole（ConPTY）补齐了 Windows 支持。

平台差异需要注意：

Windows 没有 termios
没有 child process 的话，没有 echo
ConPTY 会对输出做重新编码

但对跨平台 CLI 工具来说，「能在三个平台跑同一份代码」本身就是巨大的简化。

8) 原生 `using` / `await using`

Bun 不再把 using / await using 声明转译成辅助函数调用——前提是 target 是 Bun：

bun run
Bun.Transpiler({ target: "bun" })
bun build --target=bun

这意味着资源管理（文件句柄、连接、锁）可以用规范语法写，且没有运行时开销。

typescript

{
  using db = openDatabase();
  // ...
} // db 自动关闭

9) `process.execve()`：与 Node 24 对齐

javascript

process.execve("/usr/bin/echo", ["echo", "hello"], { PATH: process.env.PATH });

注意：在 Worker 线程和 Windows 上会抛错。

10) 其他「不显眼但值钱」的修复与对齐

Node.js 兼容性

修复 node:http 中 NodeHTTPResponse 缓冲未释放的内存泄漏
修复 res.setTimeout() 保活 event loop
修复 https.request() 忽略 checkServerIdentity 回调
修复 node:zlib 的 onerror 回调 use-after-free
修复 crypto.scrypt 分配失败时的内存泄漏
修复 crypto.randomFill 越界堆溢出
修复 Buffer.copyBytesFrom() 在 byteOffset 非零时的行为
修复 node:http2 在重入 JS 回调时的 use-after-free
修复 ESM 顶层 await 在循环模块图中的处理

Bun API

修复 TLS server ALPN 回调 use-after-free
修复 Bun.spawn 的 stdin 管道泄漏
修复 Bun.serve() 在 ReadableStream / FormData 路径下的内存泄漏
修复 Bun.RedisClient 在重连失败后卡死
修复 Bun.FileSystemRouter 的崩溃与内存泄漏

bun:sql

修复 PostgreSQL 连接失败后不被 GC
修复 MySQL 存储过程在第一个结果集后就 resolve
修复 MySQL BLOB 参数在 GC 期间被破坏
修复 PostgreSQL 数组列内存泄漏（每 1000 次迭代约 72MB）

Web API（这里有几个会直接影响业务）

修复 FormData 多部分边界格式与 WebKit 对齐——之前会导致 OpenAI API 偶发 400
修复 TextDecoder UTF-16 内存泄漏
修复 Blob / File 显示 [detached] 的问题
修复 TLS ClientHello 中 ECH GREASE 导致 fetch 卡死
修复 WebSocket.close() 在 CONNECTING 阶段时 socket 卡住
修复 TransformStream 的 GC root 环导致 OOM

如果你之前在 OpenAI / Anthropic API 调用上偶尔遇到莫名其妙的 400 或卡死，这次升级值得专门提一下。

11) 性能与体积

这部分对「不升级也不会出错，但升级了就能直接受益」的同学：

内存：单 VM 共享 SSL_CTX 缓存——MongoDB/Mongoose 场景 1000 次迭代 RSS 从 ~1 GB 降到 ~168 MB
JavaScriptCore：跟到 565 个上游提交（更快的 async return without await、Array.prototype.shift fastShift、短字符串 JSON.parse、单字符 startsWith / endsWith、Intl.NumberFormat 创建）
跨语言 LTO（Linux）：Zig 导出 → C++ 函数消除 42%，C us_* ← Zig 69%，C++ uws_* ← Zig 70%，mi_free 100%
- 实际收益：Bun.escapeHTML 快 6.5%、TextDecoder.decode 快 2.6%、HTTP 吞吐快 3.5%
ESM 加载：500 个 ESM 文件 ~140ms → ~123ms（约快 12%）
GC 开销：去掉了 ~63 种内建对象类型在增量 GC 中的冗余重扫
二进制体积：
- Windows aarch64: -18.42 MB
- Windows x64: -17.66 MB
- Linux aarch64: -9.07 MB
- Linux x64: -8.58 MB
SQLite：3.51.2 → 3.53.0
tls.getCACertificates('system')：无需 --use-system-ca 即可返回系统 CA；macOS 不再因为网络 OCSP/CRL/AIA 拉取而卡 10 秒；Windows 新增加载 CA、TrustedPeople、GROUP_POLICY、ENTERPRISE 存储

平台支持

新增 FreeBSD 与 Android 的第一方原生构建。

升级建议

升级命令：

bash

# 已安装
bun upgrade
 
# 全新安装
curl -fsSL https://bun.sh/install | bash

我的升级 checklist：

直接升级，这是个补丁版本号，不引入破坏性变更
如果你在做 Monorepo：开 install.globalStore，测一次 isolated linker
如果你之前装 sharp 是「只用 metadata + resize」：尝试切到 Bun.Image，看看能不能把原生依赖踢掉
如果你在生产里调 OpenAI / Anthropic / Cloudflare 等大厂 API：留意 FormData 与 ECH GREASE 这两个修复，过去偶发的小问题可能就此消失
HTTP/3 服务、fetch() HTTP/2/3 都还是 experimental，先在非关键链路上跑跑数据，再决定要不要打开

我的总体评价

Bun 1.3.14 不是一次「换个版本号」的发布，它有几个我认为值得记住的方向：

运行时正在持续吃掉原本的「装库」需求：sharp、HTTP/3 server、HTTP/2/3 client、PTY……Bun 把「装一个原生模块」往「直接用运行时 API」推
isolated 装包模式的速度问题被一次性解决：pnpm 之外，第二个把虚拟存储做到生产可用的工具链
打磨没有停：JavaScriptCore 跟到 565 个上游提交、跨语言 LTO、ESM 加载提速、GC 减负、二进制瘦身

如果你已经在用 Bun，这是个强烈建议升级的版本；如果你还在「Node vs Bun」之间纠结，这次发布把天平又往 Bun 一边推了一点。

参考链接

Bun 1.3.14 发布文：https://bun.com/blog/bun-v1.3.14
Bun 官网：https://bun.com/
Bun 文档：https://bun.com/docs
Bun.Image 文档：https://bun.com/docs/api/image
isolated linker：https://bun.com/docs/install/linker
HTTP/3 (Bun.serve)：https://bun.com/docs/api/http
lsquic：https://github.com/litespeedtech/lsquic

图像处理不再需要装 sharp
HTTP/3 不再需要 nginx / Caddy 反代
隔离式 link 装包，从「慢一点」变成「快 7 倍」
fetch() 自己长出了 HTTP/2 与 HTTP/3 客户端
还顺带把 JavaScriptCore 跟到了 565 个上游提交

下面按「你为什么应该关心」的顺序，把这次发布拆开讲。

先给结论：v1.3.14 的主线是什么？

Bun 1.3.14 的更新可以归到三条主线：

能力内置化：图像处理（Bun.Image）、HTTP/3 服务、fetch 的 HTTP/2/3 客户端、Windows 上的 Bun.Terminal——都是「原本需要装库才能做」的事，现在变成了运行时自带。
包管理向 isolated linker 倾斜：新增 install.globalStore，让 --linker=isolated 在大型 Monorepo 下的速度，从「比 hoisted 慢一点」直接变成「快一个数量级」。
基础设施持续打磨：fs.watch() 后端重写、JavaScriptCore 升级、跨语言 LTO、ESM 加载更快、二进制体积变小、内存占用下降。

外加几个偏「细节地狱」但很值钱的修复：FormData 多部分边界格式（影响 OpenAI API）、ECH GREASE 导致的 fetch 卡死、MySQL BLOB 在 GC 时被破坏，等等。

1) `Bun.Image`：把 sharp 的 80% 写进运行时

这一项是这次发布里覆盖面最广、感知最直接的能力。

Bun 1.3.14 新增了 Bun.Image —— 一个链式调用的图像处理 API。能力范围：

输入：路径、ArrayBuffer / TypedArray、Blob / BunFile / S3File、data: URL
变换：resize、rotate、flip、flop、modulate
重采样滤镜：nearest、box、bilinear、cubic、mitchell、lanczos2/3、mks2013、mks2021（与 sharp 对齐）
输出：bytes() / buffer() / blob() / toBase64() / dataurl() / placeholder()（thumbhash）/ metadata() / write()
格式：全平台支持 JPEG / PNG / WebP / GIF / BMP；macOS & Windows 额外支持 HEIC / AVIF / TIFF
线程模型：除 metadata() 外都在主线程之外执行

官方示例：

javascript

await Bun.file("photo.jpg")
  .image()
  .resize(1024, 1024, { fit: "inside" })
  .rotate(90)
  .webp({ quality: 85 })
  .write("thumb.webp");

性能对比（vs sharp 0.34.5）：

metadata()：~70× 更快
1080p PNG → 400×400 → JPEG：1.38× 更快
4K JPEG → 1920×1080 → JPEG：1.22× 更快

少一个 node-gyp / 原生模块构建链路。

任何在 Docker / 边缘运行时部署过 sharp 的人都会理解这句话的价值。

2) 全局虚拟存储：让 isolated linker 终于「真的快」

1.3.14 引入了 install.globalStore 选项，把所有项目共享一个全局虚拟存储池。

基准（Apple Silicon、1400 个包的 fixture）：

Linker 模式	耗时
Hoisted	823ms
Isolated（旧）	841ms
Isolated + globalStore	115ms

clonefileat 系统调用次数：0。

启用方式（bunfig.toml）：

toml

[install]
globalStore = true

或者用环境变量：

bash

BUN_INSTALL_GLOBAL_STORE=1 bun install

为什么这件事重要：

Monorepo 场景：以前选 isolated 是「为了安全付出性能代价」，现在不用选了
CI 缓存：全局存储天然适合做跨任务缓存
磁盘占用：跨项目去重，比每个 repo 自己 node_modules 节省

如果你之前因为「太慢」而没用 isolated linker，这次值得重新评估。

3) Bun.serve 加上 HTTP/3 支持（实验性）

Bun.serve 现在可以直接吐 HTTP/3，由 lsquic v4.6.2 驱动。

javascript

Bun.serve({
  port: 443,
  tls: { cert, key },
  http3: true,
  fetch(req) { return new Response("hi"); },
});

官方给出的吞吐数据（Linux x64）：

场景	HTTPS/1.1	HTTP/3
静态路由	189,130 req/s	509,135 req/s
动态 fetch handler	142,323 req/s	283,485 req/s

但目前还有不少限制，官方明确标注「highly experimental」：

不支持 HTTP/3 上的 WebSocket
0-RTT 暂未启用
不支持 Unix sockets
不支持 trailers
不支持 Expect: 100-continue

我的判断：

生产侧：建议先观望；HTTP/3 的真正瓶颈通常在客户端、CDN、网络中间件，不是源站
场景侧：如果你做的是直连边缘 + 弱网移动客户端（比如 IoT、游戏后端、实时音视频信令），可以提前在 staging 验证

4) `fetch()` 的 HTTP/2 与 HTTP/3 客户端（实验性）

这是这次发布里我个人最期待的能力之一。

Bun 内置 fetch() 一直只跑 HTTP/1.1。1.3.14 同时上了两个实验性客户端：

HTTP/2

开启方式：

bash

# 全局开关
BUN_FEATURE_FLAG_EXPERIMENTAL_HTTP2_CLIENT=1 bun run app.ts
# 或 CLI flag
bun --experimental-http2-fetch app.ts

或者按请求开启：

javascript

const res = await fetch("https://example.com", { protocol: "http2" });

能力清单：

多路复用（multiplexing）
连接复用（coalescing）
keep-alive 池化
请求体流式上传
REFUSED_STREAM / GOAWAY 自动重试
Content-Length 严格校验（RFC 9113 §8.1.1）
Expect: 100-continue
HPACK bomb 防护（256 KiB 上限）
PING 反射防护（1 MiB 上限）

不支持：HTTP 代理 / CONNECT、Unix sockets、server push、明文 HTTP/2（h2c）。

HTTP/3

javascript

const res = await fetch("https://example.com/", { protocol: "http3" });

支持所有 HTTP 方法、重定向、gzip、ReadableStream 上传、全双工流、AbortSignal，以及 Alt-Svc 协商的 HTTP/3 升级（RFC 7838，需要 --experimental-http3-fetch）。

为什么这件事值得关注：

之前在 Bun 里要发 HTTP/2 请求，要么用 Node 兼容层的 node:http2，要么外挂一个 client。现在「fetch() 直接说话」，对调用云厂商 API、对接 gRPC-Web、跨区域回源等场景，是真实的减负。

5) `fs.watch()` 完全重写：Linux / macOS / FreeBSD

fs.watch() 是 Node 生态老大难。Bun 这次直接对接 OS 原生 API：

Linux：inotify
macOS：FSEvents
FreeBSD：kqueue

伴随的修复：

Linux 递归监听：现在能正确捕获「监听期间新建的子目录」
Linux 删后重建：被删后又重建的文件会重新触发 change 事件
macOS 线程：不再为同一个 watcher 拉起两个线程

如果你之前在 dev server、热重载、chokidar 这条链上踩过「watcher 偶尔不触发」的坑，这次升级就是答案。

6) `bun --no-orphans`：进程死了，孩子也别活着

一个看起来很小、但实际很解气的 flag：

bash

bun --no-orphans run my-script

行为：父进程一旦死亡，递归 SIGKILL 所有后代进程。

实现上：

Linux：prctl(PR_SET_PDEATHSIG, SIGKILL)
macOS：kqueue 的 EVFILT_PROC / NOTE_EXIT
用「停 → 验证 → 杀」的策略避免 PID 重用风险

适用场景非常具体但很高频：

本地 dev server 启了 sub-process，但 Ctrl+C 后子进程残留
CI 任务超时被杀，但派生出来的 Playwright / Vite / esbuild 还在跑
容器里跑测试时，僵尸进程拖死整个 pod

以前要靠 tini / dumb-init / 自己写 trap，现在加一个 flag 就行。

7) Windows 上的 `Bun.Terminal`（ConPTY）

Bun.Terminal 之前只在 macOS / Linux 上能用。1.3.14 通过 CreatePseudoConsole（ConPTY）补齐了 Windows 支持。

平台差异需要注意：

Windows 没有 termios
没有 child process 的话，没有 echo
ConPTY 会对输出做重新编码

但对跨平台 CLI 工具来说，「能在三个平台跑同一份代码」本身就是巨大的简化。

8) 原生 `using` / `await using`

Bun 不再把 using / await using 声明转译成辅助函数调用——前提是 target 是 Bun：

bun run
Bun.Transpiler({ target: "bun" })
bun build --target=bun

这意味着资源管理（文件句柄、连接、锁）可以用规范语法写，且没有运行时开销。

typescript

{
  using db = openDatabase();
  // ...
} // db 自动关闭

9) `process.execve()`：与 Node 24 对齐

javascript

process.execve("/usr/bin/echo", ["echo", "hello"], { PATH: process.env.PATH });

注意：在 Worker 线程和 Windows 上会抛错。

10) 其他「不显眼但值钱」的修复与对齐

Node.js 兼容性

修复 node:http 中 NodeHTTPResponse 缓冲未释放的内存泄漏
修复 res.setTimeout() 保活 event loop
修复 https.request() 忽略 checkServerIdentity 回调
修复 node:zlib 的 onerror 回调 use-after-free
修复 crypto.scrypt 分配失败时的内存泄漏
修复 crypto.randomFill 越界堆溢出
修复 Buffer.copyBytesFrom() 在 byteOffset 非零时的行为
修复 node:http2 在重入 JS 回调时的 use-after-free
修复 ESM 顶层 await 在循环模块图中的处理

Bun API

修复 TLS server ALPN 回调 use-after-free
修复 Bun.spawn 的 stdin 管道泄漏
修复 Bun.serve() 在 ReadableStream / FormData 路径下的内存泄漏
修复 Bun.RedisClient 在重连失败后卡死
修复 Bun.FileSystemRouter 的崩溃与内存泄漏

bun:sql

修复 PostgreSQL 连接失败后不被 GC
修复 MySQL 存储过程在第一个结果集后就 resolve
修复 MySQL BLOB 参数在 GC 期间被破坏
修复 PostgreSQL 数组列内存泄漏（每 1000 次迭代约 72MB）

Web API（这里有几个会直接影响业务）

修复 FormData 多部分边界格式与 WebKit 对齐——之前会导致 OpenAI API 偶发 400
修复 TextDecoder UTF-16 内存泄漏
修复 Blob / File 显示 [detached] 的问题
修复 TLS ClientHello 中 ECH GREASE 导致 fetch 卡死
修复 WebSocket.close() 在 CONNECTING 阶段时 socket 卡住
修复 TransformStream 的 GC root 环导致 OOM

如果你之前在 OpenAI / Anthropic API 调用上偶尔遇到莫名其妙的 400 或卡死，这次升级值得专门提一下。

11) 性能与体积

这部分对「不升级也不会出错，但升级了就能直接受益」的同学：

内存：单 VM 共享 SSL_CTX 缓存——MongoDB/Mongoose 场景 1000 次迭代 RSS 从 ~1 GB 降到 ~168 MB
JavaScriptCore：跟到 565 个上游提交（更快的 async return without await、Array.prototype.shift fastShift、短字符串 JSON.parse、单字符 startsWith / endsWith、Intl.NumberFormat 创建）
跨语言 LTO（Linux）：Zig 导出 → C++ 函数消除 42%，C us_* ← Zig 69%，C++ uws_* ← Zig 70%，mi_free 100%
- 实际收益：Bun.escapeHTML 快 6.5%、TextDecoder.decode 快 2.6%、HTTP 吞吐快 3.5%
ESM 加载：500 个 ESM 文件 ~140ms → ~123ms（约快 12%）
GC 开销：去掉了 ~63 种内建对象类型在增量 GC 中的冗余重扫
二进制体积：
- Windows aarch64: -18.42 MB
- Windows x64: -17.66 MB
- Linux aarch64: -9.07 MB
- Linux x64: -8.58 MB
SQLite：3.51.2 → 3.53.0
tls.getCACertificates('system')：无需 --use-system-ca 即可返回系统 CA；macOS 不再因为网络 OCSP/CRL/AIA 拉取而卡 10 秒；Windows 新增加载 CA、TrustedPeople、GROUP_POLICY、ENTERPRISE 存储

平台支持

新增 FreeBSD 与 Android 的第一方原生构建。

升级建议

升级命令：

bash

# 已安装
bun upgrade
 
# 全新安装
curl -fsSL https://bun.sh/install | bash

我的升级 checklist：

直接升级，这是个补丁版本号，不引入破坏性变更
如果你在做 Monorepo：开 install.globalStore，测一次 isolated linker
如果你之前装 sharp 是「只用 metadata + resize」：尝试切到 Bun.Image，看看能不能把原生依赖踢掉
如果你在生产里调 OpenAI / Anthropic / Cloudflare 等大厂 API：留意 FormData 与 ECH GREASE 这两个修复，过去偶发的小问题可能就此消失
HTTP/3 服务、fetch() HTTP/2/3 都还是 experimental，先在非关键链路上跑跑数据，再决定要不要打开

我的总体评价

Bun 1.3.14 不是一次「换个版本号」的发布，它有几个我认为值得记住的方向：

运行时正在持续吃掉原本的「装库」需求：sharp、HTTP/3 server、HTTP/2/3 client、PTY……Bun 把「装一个原生模块」往「直接用运行时 API」推
isolated 装包模式的速度问题被一次性解决：pnpm 之外，第二个把虚拟存储做到生产可用的工具链
打磨没有停：JavaScriptCore 跟到 565 个上游提交、跨语言 LTO、ESM 加载提速、GC 减负、二进制瘦身

如果你已经在用 Bun，这是个强烈建议升级的版本；如果你还在「Node vs Bun」之间纠结，这次发布把天平又往 Bun 一边推了一点。

参考链接

Bun 1.3.14 发布文：https://bun.com/blog/bun-v1.3.14
Bun 官网：https://bun.com/
Bun 文档：https://bun.com/docs
Bun.Image 文档：https://bun.com/docs/api/image
isolated linker：https://bun.com/docs/install/linker
HTTP/3 (Bun.serve)：https://bun.com/docs/api/http
lsquic：https://github.com/litespeedtech/lsquic

先给结论：v1.3.14 的主线是什么？

1) Bun.Image：把 sharp 的 80% 写进运行时

2) 全局虚拟存储：让 isolated linker 终于「真的快」

3) Bun.serve 加上 HTTP/3 支持（实验性）

4) fetch() 的 HTTP/2 与 HTTP/3 客户端（实验性）

HTTP/2

HTTP/3

5) fs.watch() 完全重写：Linux / macOS / FreeBSD

6) bun --no-orphans：进程死了，孩子也别活着

7) Windows 上的 Bun.Terminal（ConPTY）

8) 原生 using / await using

9) process.execve()：与 Node 24 对齐

10) 其他「不显眼但值钱」的修复与对齐

Node.js 兼容性

Bun API

bun:sql

Web API（这里有几个会直接影响业务）

11) 性能与体积

平台支持

升级建议

我的总体评价

参考链接

先给结论：v1.3.14 的主线是什么？

1) Bun.Image：把 sharp 的 80% 写进运行时

2) 全局虚拟存储：让 isolated linker 终于「真的快」

3) Bun.serve 加上 HTTP/3 支持（实验性）

4) fetch() 的 HTTP/2 与 HTTP/3 客户端（实验性）

HTTP/2

HTTP/3

5) fs.watch() 完全重写：Linux / macOS / FreeBSD

6) bun --no-orphans：进程死了，孩子也别活着

7) Windows 上的 Bun.Terminal（ConPTY）

8) 原生 using / await using

9) process.execve()：与 Node 24 对齐

10) 其他「不显眼但值钱」的修复与对齐

Node.js 兼容性

Bun API

bun:sql

Web API（这里有几个会直接影响业务）

11) 性能与体积

平台支持

升级建议

我的总体评价

参考链接

1) `Bun.Image`：把 sharp 的 80% 写进运行时

4) `fetch()` 的 HTTP/2 与 HTTP/3 客户端（实验性）

5) `fs.watch()` 完全重写：Linux / macOS / FreeBSD

6) `bun --no-orphans`：进程死了，孩子也别活着

7) Windows 上的 `Bun.Terminal`（ConPTY）

8) 原生 `using` / `await using`

9) `process.execve()`：与 Node 24 对齐

1) `Bun.Image`：把 sharp 的 80% 写进运行时

4) `fetch()` 的 HTTP/2 与 HTTP/3 客户端（实验性）

5) `fs.watch()` 完全重写：Linux / macOS / FreeBSD

6) `bun --no-orphans`：进程死了，孩子也别活着

7) Windows 上的 `Bun.Terminal`（ConPTY）

8) 原生 `using` / `await using`

9) `process.execve()`：与 Node 24 对齐