大家好，我是农村程序员，独立开发者，前端之虎陈随易。

• 个人网站 1️⃣：https://chensuiyi.me
• 个人网站 2️⃣：https://me.yicode.tech

如果本文能给你提供启发或帮助，欢迎一键三连，给我一些鼓励~

---

前言

天下苦 Node 久矣，群雄揭竿而起，势必要从 Node 嘴上扯下一块肉来。

目前 JavaScript 后端开发界有三大运行时：Node，Deno，Bun。

Node 老将，自不必多说。

Deno 已经发布了 v2 版本，势头强劲。

Bun 也已经支持 Windows、Linux、MacOS 三大操作系统，俘获不少粉丝。

目前短兵相接，开始进入近身搏斗阶段。

其中 Deno，高举互联网标准，运行时安全，原生 TypeScript 支持，内置统一开发工具等特性，稳扎稳打。

而 Bun，以整活最为出名，不得不说，确实整出了一些令人眼前一亮的功能和体验。

而本文，分享新鲜出炉的，Bun 的最新整活 Bun.s3。

正文

起因呢，是 Bun 官方在 2024年12月29日，发出了上面这张图，并附带了下面这段话：

在下一版 Bun 中

Bun 获得对 S3 的一流支持。上传、下载、流式传输和预签名无需任何依赖项。

什么意思？

就是说，Bun 将内置 对象存储 的相关操作，S3 是 aws(亚马逊云服务商) 的 对象存储 方案，也是目前事实上的对象存储标准。

国内的阿里云的 OSS，腾讯云的 COS 等，基本都是 S3 这一套协议。

那么既然如此，Bun 官方便一不做，二不休，准备把这个做成 Bun 的内置接口。

咱们继续看看使用效果。

当你将 新响应 传递给 S3 文件时，它会重定向到预先签名的过期 URL。

这样你就不会浪费服务器的资源下载到 S3 并发送给用户。

该 API 的设计工作方式与 Response、Blob 和 Bun.file(path) 非常相似，因此您可以像从本地文件系统或 fetch() 一样从 S3 读取。

Bun.write() 也获得了对 S3 的支持。

Bun.write() 可以将对象从 S3 直接下载到磁盘，也可以将本地文件直接上传到 S3。

Bun.s3 可以与以下产品配合使用：

• AWS S3
• Google Cloud Storage
• Cloudflare R2
• Backblaze B2
• Hetzner Object Storage
• DigitalOcean Spaces
• 更多供应商

有许多不同的与 S3 兼容的对象存储 API。

如果做过阿里云，腾讯云 对象存储 的对接，应该很容易看明白上面的代码。

对于这个 骚 操作，我只能说一个字：绝！

这是把 对象存储 完全当成本地硬盘来用了，除了 Bun，其他两个还真干不出来。

讨论

说实话，这个功能，东西是个好东西，但是呢，也存在争议，大概如下：

1. 支持 Azure 和 Minio 吗？
2. 为啥叫 Bun.s3，不叫 Bun.ObjectStorage？
3. 不希望将其引入运行时，而是用单独的包，比如 bun/s3 来替代。
4. 应该花更多时间处理 Node 的兼容，而不是这种花里胡哨的事情上。

来看看作者的回复：

我们为 Bun 添加了 S3 支持，因为与 S3 兼容的对象存储服务逐渐成为互联网的文件系统 API。

用于在开发中读取和写入文件的相同 API 应该在生产中也能起作用。

S3 API 专属于特定供应商的想法已经过时了大约 10 年 - 以下是一些与 S3 兼容的对象存储服务：

• Google Cloud Storage (具有互操作性模式)
• IBM Cloud Object Storage
• Oracle Cloud Infrastructure Object Storage
• Cloudflare R2
• 阿里云 OSS
• MinIO
• Ceph
• 腾讯云对象存储
• Backblaze B2
• DigitalOcean Spaces
• Linode Object Storage
• Vultr Object Storage
• OVHcloud Object Storage
• Scaleway Object Storage

尾言

笔者认为，Bun 的创新确实令人惊叹，也能倒逼 Node 和 Deno 做得更好。

但是，如果把 对象存储 相关的接口内置到 运行时 里，确实会造成运行时更加复杂，庞大。

内核方面的东西，稳定大于一切。

我更希望，有一个独立的包来做这个事情，也更方便维护和代码贡献。

不知道你怎么看呢？欢迎在评论区留言。