Bun 1.4 正式发布：从 Zig 改写为 Rust，内置浏览器、图片处理和并行测试

2026 年 8 月 20 日，Bun 1.4 正式发布。

这次更新不只是"跑得更快"：Bun 的主体实现从 Zig 迁移到了 Rust，同时继续补齐 Node.js 兼容性，并把图片处理、无头浏览器、定时任务、终端控制等能力直接放进运行时。

如果只看一句结论：Bun 1.4 值得新项目尝试，老项目则适合先开升级分支，不建议未经回归测试直接替换生产环境。

说明：本文命令与行为已按 Bun 1.4 官方发布说明逐项核对。不同系统、依赖和业务负载差异较大，生产环境仍应自行测试。

一、这次更新到底大不大？

先看几个官方数据：Bun 1.4 新增通过了 1517 项 Node.js 测试，修复超过 2900 个问题；官方测试中，空闲 CPU 占用最多降低 5 倍，内存最多减少 35%，Linux 启动速度提升约 50%。

不过，这些都是 Bun 团队在特定场景下得到的结果，不能直接等同于你的项目也会获得同样提升。真正值得开发者关注的，是下面四类变化：

变化	实际价值
从 Zig 改写为 Rust	运行时底层完成大规模迁移，后续维护路线更清晰
Node.js 兼容性继续提升	Playwright、Vitest、Next.js 等常见工具的可用范围扩大
更多能力内置	图片处理、浏览器控制、Markdown、定时任务、终端控制减少外部依赖
测试与依赖工具增强	并行测试、分片测试、漏洞修复和依赖去重更适合工程化项目

需要特别注意：Bun 官方仍明确表示，它还没有做到 100% 兼容 Node.js。涉及原生扩展、旧框架或复杂构建插件的项目，依旧要实测。

二、三个最实用的新能力

1. Bun.Image：运行时直接处理图片

Bun 1.4 可以直接读取、缩放、旋转并转换图片，不必先安装 Sharp 一类扩展。下面是官方示例的简化用法：

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

这对缩略图服务、上传预处理、静态站点构建和批量素材转换很实用。常见的 JPEG、PNG、WebP、GIF、BMP 均受支持，部分系统还支持 HEIC、AVIF 和 TIFF。

2. Bun.WebView：五行代码驱动浏览器

await using view = new Bun.WebView({ width: 800, height: 600 });
await view.navigate("https://bun.sh");
await view.click("a[href='/docs']");
const title = await view.evaluate("document.title");
await Bun.write("page.png", await view.screenshot());

它适合页面截图、简单自动化和轻量测试，但暂时不应被理解为 Playwright 的完整替代品。该功能目前仍是实验特性；macOS 使用系统 WebKit，Linux 和 Windows 则需要已安装 Chrome、Chromium、Edge 或 Brave。

3. 测试终于更适合大型项目

# 按 CPU 核心数并行运行测试文件
bun test --parallel

# 固定 4 个工作进程
bun test --parallel=4 --isolate

# 只跑相对 main 分支受影响的测试
bun test --changed=main

# 将测试拆到 3 台 CI 机器中的第 1 台
bun test --shard=1/3

并行模式会默认启用隔离，并合并覆盖率与 JUnit 结果。项目如果共用测试数据库、固定端口或临时目录，应先按 BUN_TEST_WORKER_ID 做资源隔离，否则提速后反而可能出现偶发失败。

三、依赖管理也补上了关键拼图

Bun 1.4 新增了几条很适合放进日常开发和持续集成的命令：

# 只预览漏洞修复方案，不立即修改依赖
bun audit fix --dry-run

# 检查锁文件中能否消除重复版本
bun dedupe --check

# 部署镜像中移除开发依赖
bun prune --production

bun audit fix 会尝试把存在漏洞的包升级到安全版本；涉及主版本升级时，默认不会悄悄跨版本处理。即便如此，修复依赖后仍然必须运行测试，不能把"漏洞消失"当成"业务一定兼容"。

四、推荐的升级顺序

不要在主分支上直接执行升级，先保留可回退路径：

git switch -c chore/upgrade-bun-1-4

bun --version
bun upgrade
bun install --frozen-lockfile

bun test
bun test --parallel=4
bun run build
bun audit

git diff -- package.json bun.lock

如果 --frozen-lockfile 报错，说明当前锁文件与安装结果无法保持不变。此时可以在升级分支执行 bun install，但必须检查 bun.lock 的变化，再重新跑完整测试。

升级时可以让 ChatGPT 或 Codex 帮忙归类 Node.js 兼容性报错，但提交日志前要删除令牌、连接串和业务数据；如需第三方 AI 会员服务，可自行了解 gpt68.com，该站不是 OpenAI、Anthropic 或 Bun 官方服务，使用前请自行核对账号地区、支付与售后风险。

五、升级前一定要看的两个坑

1. 定时任务默认时区变了

Bun 1.4 中，进程内 Bun.cron() 和 Bun.cron.parse() 从默认使用 UTC 改为使用进程本地时区。旧项目如果依赖 UTC，需要显式指定：

Bun.cron("0 9 * * *", handler, { tz: "UTC" });

容器、开发机和服务器的时区可能不同，这一项应列入升级检查表。

2. Markdown 输出不会自动净化

Bun.markdown 虽然方便，但生成 HTML 时会保留原始 HTML、事件属性和 javascript: 链接。用户提交的 Markdown 不能直接渲染到页面，仍需经过可靠的内容净化流程。

总结

Bun 1.4 最重要的意义，不是又多了几个命令，而是它正在从"速度很快的 JavaScript 运行时"变成一套更完整的开发工具链。

新项目可以优先试用内置图片处理、并行测试和依赖审计；已有 Node.js 项目则应从兼容性测试开始，重点检查原生依赖、定时任务时区、并行测试资源冲突和 Markdown 安全边界。

如果这些检查都能通过，Bun 1.4 才真正算得上一次有价值的升级。

参考资料：

• Bun 1.4 官方发布说明
• Bun WebView 官方文档
• Bun Test Runner 官方文档