8 月 19 日，Hacker News 上最热的帖子还是《Bun 1.4 Rust rewrite is not looking good?》：过去三个月版本发布完全停摆、5000 多个未合并 PR 堆积、提交列表里 AI 机器人排在人类贡献者前面。Hacker News 第二天 8 月 20 日，Bun 1.4 正式发布——这是 Bun 从 Zig 重写为 Rust 之后的第一个正式版，也是 Bun 诞生以来争议最大的一个版本。争议和发布隔了一天先后到达，这个版本值得写 JS 的人认真拆一遍。
53 万行代码、11 天、16.5 万美元：这是一次什么样的重写
Bun 官方在同一篇重写博文里披露了两件事：Bun 在 2025 年 12 月被 Anthropic 收购；这次 Rust 重写主要用的是未正式发布的 Claude Fable 5。Bun 官方博客 收购背景解释了重写为什么能这么"烧"：一个工程师驱动约 64 个并行 Claude，把 53.5 万行 Zig 代码、1,448 个源文件在 11 天里整体移植成 Rust，6,778 次提交、净增超 100 万行，API 消耗按标价约 16.5 万美元。微博 作为对照，官方估计人工重写需要 3 名熟悉代码库的工程师整整一年，期间所有 bug 修复和功能开发都要冻结。
比速度更关键的是两条底线：Linux 上 138 万条 expect() 断言全部通过，0 个测试被跳过或删除；重写引入的 19 个已知回归已全部修复。Claude Code 从 v2.1.181 起就在用这版 Rust Bun，Linux 启动快 10%，官方的描述是"几乎没人注意到，无聊是好事"；Prisma Compute 公测也直接跑在它上面。生产级用户已经替所有人试了两个月的水。
兼容性：1.0 以来最大跃升，但官方承认还不是 100%
Bun 1.4 新增了 1,517 个 Node.js 官方测试套件的测试通过，官方称之为"自 Bun 1.0 以来最大的兼容性跃升"：node:http、node:fs、node:stream 等 7 个核心模块通过 Node 自身测试的 97%，node:quic 99%，node:events、node:sqlite 100%。落到实际生态：Playwright 可以在 Bun 上驱动浏览器跑测试，vitest 的 --coverage 可用，`bun --bun next build` 能跑带 Turbopack 和 React Compiler 的 Next.js 16.3，dd-trace 和 OpenTelemetry 的插桩也补齐了。
但要说清楚：官方同一页也写明"Bun is not 100% compatible with Node.js yet"。生产环境跑长尾服务的人，仍要把兼容性当加分项而不是必保项，先跑自己的回归再说话。
性能与内存：这组数据才是换它的理由
启动：Linux 上 hello.js 5.1ms，1.3 是 10.9ms，同机 Node 26 要 27.2ms；Windows 启动直接快 2.5 倍。内存：fastify 峰值从 1.3 的 233MB 降到 120MB（−48%），比 Node 的 156MB 还低；1.3 里 Next.js App Router SSR 无限增长的内存泄漏被修复，渲染 4,000 页后稳定在 238MB，同场景 Node 是 410MB。
空闲 CPU 降到原来的 1/5，Claude Code 生产环境 p99 CPU 从 24% 降到 10%。可观测性也补齐了：bun --cpu-prof 的产物可以直接用 Chrome DevTools 打开，新增的 --cpu-prof-md 把性能报告输出成 Markdown，SSH 到服务器上 grep 一下就能定位热点函数。
官方还修掉了 128 个在 1.3.14 上可复现的 bug，以内存泄漏和崩溃为主。不过社区质疑的"约 4% 代码还在 unsafe 块里"也属实，官方的承诺是持续重构把这个比例往下压——这是接下来几个月最值得盯的技术指标之一。
工具链：就算不换运行时，也值得先偷这三样
Bun 1.4 把 15 个常用依赖直接内置进二进制：Bun.Image 处理图片比 sharp 快 1.38 倍，Bun.WebView 是内置无头浏览器，再加上 Bun.markdown、Bun.cron()、Bun.Terminal，脚本型和小工具项目可以做到真正零依赖分发，npm install 这一步直接消失。
包管理和测试也在继续拉差距：T3 栈实测项目 bun install 首次安装 1.41 秒，同机 npm 要 18.1 秒；bun test --parallel 按历史耗时智能分片后，最慢分片从 18.1s 降到 13.3s。用 Node 当运行时、Bun 当工具链，已经是不少团队的稳态打法——install、test、run 全交给 Bun，生产仍走 Node，零风险先吃速度红利。
争议没结束：发布前一天，社区还在列问题
别只看官方数字。发布前一天那篇 HN 热帖和国内社区的质疑集中在三处：Zig 时代每 2-3 周发一版的节奏，在 Rust 重写开始后完全停摆了三个月；5,000 多个未合并 PR 远超健康开源项目的水位；贡献榜上 robobun、autofix-ci 这些 AI 账号的提交量远超人类。微博 知乎上有人直接质疑 AI 重写后的可维护性，认为模型的目标是通过测试而不是架构与设计：“他的重写版本一定塞了很多slop，只是没有展露出来”。知乎
反转过的事实也要讲：被广泛引用的"Buz 项目发现 1.1 万行死代码"，实际出自 Rust 重写之前的 Zig 版 fork，批评对象就错了；也有日常使用者在 HN 回帖"我每天都在用，基本没见过回归"。Hacker News Zig 作者 Andrew Kelley 的怒喷与 Jarred 的回应，更像两种语言阵营的旧怨公开化，本身不构成用不用 1.4 的理由。真正没人能回答的问题只有一个：一个主要由 AI 写代码、AI 审代码的开源项目，能不能长期稳定迭代。这个问题现在没有答案，只能看信号。
换还是等：三类人三种打法
Node 稳定生产党：别动运行时。先把 bun install、bun test、bun run 换进工作流，工具链提速立竿见影、成本几乎为零；运行时等 1.4 出两三个补丁版再评估。
新项目、脚本工具、边缘场景党：1.4 值得直接上。启动、内存、单二进制分发的优势都是实测级，但做两件事：跑一遍自己的回归测试套件；保留一条回 Node 的退路。
已在 Bun 上的用户：直接升 1.4，重点核对那 19 个已修复回归里有没有命中你的业务，尤其是 React HMR 和时间处理相关的边界场景。
继续观察的信号：1.4.1/1.4.2 的补丁节奏、unsafe 占比的下降曲线、5,000 个 PR 的清理进度、官方 Node 兼容性看板是否继续爬升。两个月后这四条曲线都健康，这台"AI 重写的运行时"才算真正通过试用期。
