Bun 团队去年决定把核心迁移到 Rust，等于宣判了 Zig 版本的死刑。一位在 Ziggit 论坛发帖、ID 为 solenopsys 的开发者没有认领这个判决，而是把 Bun 最后一个 Zig 版本整体裁剪，移植到原生 Zig 0.16，取名 Cruller。
它只做一件事：加载预构建好的 JavaScript 服务并跑起来。包管理器、打包器、转译器、Shell、测试运行器、N-API、SQL 客户端——这些开发时才用得上的模块全部砍掉。剩下的是 JavaScriptCore 执行引擎、Bun.serve、HTTP/1-3、WebSocket、fetch 和流。
按作者给出的数据，ReleaseFast 剥离版体积约 73.0 MiB，官方 Bun 1.3.14 是 88.5 MiB，缩小了将近 18%。这组数字来自作者自测，没有第三方复核。
裁掉了什么，换来了什么
Cruller 的逻辑很简单：开发用完整工具链，部署用瘦身运行时。两者分开打包，谁都不用背着对方的重量走。
| 项目 | 官方 Bun 1.3.14 | Cruller ReleaseFast |
|---|---|---|
| 体积 | 88.5 MiB | 73.0 MiB |
| 包管理器/打包器/转译器 | 保留 | 移除 |
| Shell/测试运行器/N-API | 保留 | 移除 |
| JS 执行引擎 | JavaScriptCore | JavaScriptCore（保留） |
| 支持平台 | 多平台 | 仅 Linux x64 |
体积缩小的代价是使用场景变窄。Cruller 只能加载预构建入口，不能临时跑脚本、装包、起 Shell。它服务的不是日常开发，是已经定型的生产部署。
性能上作者用 V8 Crypto 纯 JS 基准测过一次，Cruller 中位数比官方 Bun 高约 2%。这个差距他自己归为正常波动，不算实质优势。Cruller 的卖点从来不是更快，是更小、更适合塞进受限环境。
谁该关心这件事，谁还不用动
正在评估 Bun 生产部署成本的后端团队,现阶段不用换。开发照样用完整 Bun，Cruller 目前只适合在可控的 Linux x64 环境里做技术验证，不适合直接顶替生产环境。
真正该盯着看的是关注 Zig 嵌入式架构的开发者。作者的长期目标是把 HTTP、TLS、HTTP/3、ZMQ 这些连接器拆成独立插件，最终把整个引擎打包成带 .zig 接口的动态库，嵌入其他应用里用。这条路如果走通,才是 Cruller 真正有价值的地方,不是省下的这十几 MB。
三个现实限制值得说清楚:
- 平台单一.目前只支持 Linux x64,Windows、macOS 用户暂时用不上。
- 构建仍依赖 Bun.干净构建时代码生成阶段要靠已安装的 Bun,部分生成器还是 TypeScript 写的,没完全转成 Zig 原生。
- 单人维护.项目由一个人业余推进,没有团队,更新节奏和长期支持都不确定。
没碰的老问题：JSC 和手动内存管理
这次移植主要是兼容性搬迁,不是架构重写。作者自己说得很清楚,还没碰内部实现,Zig 0.16 引入的新 I/O 架构目前也没启用。底层依旧是 Bun 遗留的 C 库和自写 I/O 代码。
论坛里有人提出一个更根本的问题:Bun 的内存占用高,到底是 Zig 语言的锅,还是 JavaScriptCore 的垃圾回收和 Zig 手动内存管理这两套模式硬凑在一起导致的。这个矛盾 Cruller 也没解决。
作者的计划是先做一个基于 QuickJS 的独立控制层,去调 JSC 的内存参数,让运行时空闲时不要白白吃掉两三百 MB。这是缓解,不是根治。真正的架构改造还没开始。
接下来最该盯的,是 Cruller 能不能把连接器拆成插件、把引擎打包成可嵌入的动态库。这一步走通了,才谈得上生产可用；走不通,它就停在一次体积验证上。