如何利用 Bun 将包安装时间从 28 分钟缩短至 47 秒
makedream٨ مايو ٢٠٢٦
0
Computing/SoftwareRelated Video
1:20:32闲聊、Bun 的演进及更多内容！
Maximilian Schwarzmüller
Comments (0)
Log in to leave a comment
No posts yet
makedream1:20:32makedream1:20:32Maximilian Schwarzmüller
Log in to leave a comment
No posts yet
在 Node.js 环境中与臃肿的依赖项作斗争时，经常会让人分不清是在写代码还是在盯着安装进度条。Bun 不仅仅是一个极速的运行时，它还为与 AI Agent 的协作铺就了一个相当不错的平台。在速度这一表面理由的背后，让我们聊聊实际的迁移方法和架构设计故事。
Bun 是使用 Zig 语言从底层重写的。得益于此，它的包安装速度压倒性地快于 Node.js v22。但是，如果在保留现有 package-lock.json 的情况下混用 Bun，会导致锁定文件冲突，从而在部署机器上引发惨叫。在这种情况下，不要尝试笨拙的并行方案，而应该重新布局。
首先，请果断删除 node_modules 和现有的锁定文件。然后，在终端运行 bun install --frozen-lockfile，这将生成 Bun 特有的二进制锁定文件 bun.lockb。对于像 bcrypt 这样使用 C++ 插件并可能抛出编译错误的库，将其更换为 bcryptjs 或使用 Bun 内置的 API bun:sqlite 对心理健康更有利。在一个拥有超过 1,800 个依赖项的项目中，原本需要 28 分钟的操作缩短到 47 秒，这种体验是相当震撼的。
如果给基于 LLM 的 AI Agent 扔一个几千行的文件，它很快就会迷失方向并开始胡言乱语。由于 Bun 的文件 I/O 非常快，即使将文件拆得很细，也几乎不会有性能损失。为了提高 Agent 修改代码时的准确度，将单个文件保持在 100 行以内的结构会更有利。
我在项目中创建了像 src/agents、src/tools 这样功能完全分离的文件夹。然后，将 Bun.serve 与 Bun.file 结合，构建一个只能访问特定目录的网关。通过 targetPath.startsWith 验证路径，可以防止 Agent 翻动我 MacBook 系统设置的事故发生。这是一种既保证了安全又节省了 Token 成本的结构。
如果 AI Agent 调用了工具但响应迟迟不来，用户体验就会崩溃。Express 在查找路由时采用按顺序搜索的方式，因此请求增多时会变慢。相比之下，Hono 使用前缀树（Trie）算法，可以瞬间找到路径。
实际上，将 Bun 与 Hono 结合后，每秒查询数 (RPS) 可飙升至约 41,800 次。这比 Express 快 3 倍以上。请通过 bun add hono 开始，并直接通过 Bun.env 读取环境变量。再加上 Bun 的高性能 WebSocket API，可以将实时响应延迟控制在 27ms 左右。这样就不必看着 AI 因为服务器迟钝而发呆了。
仅靠我一个人使用 Bun 是解决不了问题的。团队所有成员必须使用相同的环境，才能避免生产环境出现事故。请将 .bunfig.toml 文件放在根目录，固定私有仓库信息或锁定文件选项。这能减少新成员加入时的磨合时间。
部署时，需要注意 Docker 镜像的大小。建议以 oven/bun:1 镜像为基础，并利用 bun build --compile 选项将源代码构建为单个可执行文件。将该文件提取并放入 distroless 镜像中，原本超过 1GB 的 Node.js 镜像可以缩小到 200MB 以下。镜像体积变小后，云基础设施成本可降低约 40%，没有理由不这样做。