大家好，我是农村程序员，独立开发者，前端之虎陈随易。
• 个人网站 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 做得更好。
但是，如果把 对象存储 相关的接口内置到 运行时 里，确实会造成运行时更加复杂，庞大。
内核方面的东西，稳定大于一切。
我更希望，有一个独立的包来做这个事情，也更方便维护和代码贡献。
不知道你怎么看呢？欢迎在评论区留言。
