Bun 1.4的发布说明堆了一长串新功能,开头就是2900多个bug修复、1517个新增Node.js测试用例,读起来像在证明自己有多努力。真正让我多看一眼的东西被放在功能列表末尾,轻描淡写一句带过:这个版本把Bun的核心从Zig重写成了Rust。几个月前这次重写还吵得沸沸扬扬,现在官方把它埋进了脚注。
更值得琢磨的是一个叫Bun.WebView的实验性API。Simon Willison拿它写了个大约150行的TypeScript服务,零依赖,模仿他自己维护的shot-scraper工具:开三个接口/javascript、/screenshot、/healthz,每来一个请求就开一个浏览器标签页,能并发跑JS、截图,不用装Puppeteer或Playwright。他顺手测了内存占用——跑满一个完整Chrome,容器要192到256MB。这个数字和官方那张写着"内存降低35%"的benchmark表放在一起看,挺打脸的。
发生了什么
- **Bun 1.4正式发布**,是Zig重写为Rust之后的首个稳定版本
- 新增Bun.WebView、Bun.Image、Bun.markdown、Bun.cron()等一批API,还有
bun audit fix、bun dedupe这类工具链补齐 - **Bun.WebView**支持两种后端:macOS默认走系统WebKit,或者跨平台控制Chrome/Chromium/Edge等,通过Chrome DevTools Protocol(CDP)通信
- Willison用Claude Code写的原型验证了一件事:不装重型自动化框架,也能复刻shot-scraper那套JSON API,但真跑Chrome自动化任务,内存开销比想象中高
官方数字和真实负载对不上
Bun官方给的benchmark确实好看:
| 项目 | Bun 1.3 | Bun 1.4 | 变化 |
|---|---|---|---|
| Linux 启动时间 | 10.9ms | 5.1ms | 提速约2倍 |
| Linux 峰值内存 | 33.0MB | 14.6MB | 降约56% |
| Windows 启动时间 | 39.0ms | 15.5ms | 提速约2.5倍 |
| Windows 峰值内存 | 46.5MB | 16.8MB | 降约64% |
| Claude Code CPU p99 | 24% | 10% | 降约58% |
| Fastify 内存占用 | 233MB | 120MB | 降约48% |
这些提升不是空手套白狼,主要来自JavaScriptCore分配器换成了mimalloc(以前是libpas和mimalloc混着用),再加上闲时清扫线程、更少的futex调用。1.4确实比1.3瘦了,这点没什么好质疑的。
问题在于,官方这张表里跑得最重的场景是Fastify这种普通HTTP服务,内存也才120MB。而Willison实测的Bun.WebView——只是开一个Chrome标签页,还不是跑复杂业务逻辑——就要192到256MB。一个"轻量运行时"的招牌,一碰到真实浏览器自动化就撑不住了。这不是Bun说谎,是benchmark测的是空跑场景,真实工作负载从来不按benchmark的剧本走。
- 风险.如果照着官方内存数字规划容器配额,跑浏览器自动化任务大概率会因为OOM反复重启
WebKit和Chrome,能力根本不对等
Bun.WebView的文档里藏着一个容易被忽略的细节:两种后端不是平权的。
macOS上默认用的WebKit走的是Bun自己搓的Unix socket二进制协议,不支持CDP,截图、网络监听这些高级能力都拿不到。想要shot-scraper那种完整功能,必须切到Chrome/Chromium,靠CDP通信——而且还有个前置条件:得先执行一次navigate,CDP会话才会建立,view.cdp()才能调用。这意味着如果你在macOS本地开发时用WebKit图省事,部署到Linux生产环境换成Chrome,行为和能力可能不是一回事,这个坑原文完全没提。
Bun.WebView离能用还有多远
Willison的demo证明了一件事:概念上,Bun内核集成浏览器控制是可行的,150行代码就能做出一个能用的JSON服务。这对靠Puppeteer、Playwright吃饭的自动化工具链是个信号——运行时厂商自己动手做浏览器自动化,不用装第三方框架。
但Bun.WebView目前标注为experimental,官方明确说未来可能有breaking change。这不是能直接搬去生产的东西,更像一个验证方向对不对的原型。加上WebKit和Chrome后端能力不对等、真实内存开销比官方数字高出一截,现在下"Bun要取代Puppeteer"的结论还早。
- 结论.Bun这次真正做实的是运行时基础性能(mimalloc替换带来的启动和内存优化),Bun.WebView只是一个还在长身体的实验田
Rust重写被塞进功能列表末尾,不代表这件事不重要,更像是团队不想让一次内部架构决策抢了功能发布的风头。天下熙熙,皆为利来——发布说明怎么排版,永远是给谁看服务的。读者真正该盯的,不是官方PR怎么写,是Bun.WebView从experimental转正的时间点,以及CDP能力会不会补齐到WebKit后端。这两个变量比任何一张benchmark表都更能决定它值不值得接进生产系统。