技术博客
分享开发经验、使用教程和技术洞察
只给两家云做的功能，顺手在第三处代码里挖出一个签名 bug
细粒度对象 ACL——按具体账号 ID 授权,而不是公开/私有二选一——七家云里认真查过文档后只有 AWS S3 和华为云 OBS 值得做。写华为云那份实现时,新方法一上线就报签名不匹配,原因是半年前就留了一句"用到再补"的注释,这次终于用到了却忘了回来补。
官方文档不肯说签名版本，第三方 SDK 的源码替它说了
金山云 KS3 因为找不到可验证的官方签名向量搁置之后，接下来查京东云对象存储时又撞上类似的墙——官方文档翻遍了也没有一句话明确写"这是 SigV4"。但这次没有卡住：一个第三方 PHP 客户端的源码显示它直接实例化官方 AWS SDK 的 S3Client 指向京东云，这比任何一句文档描述都更有说服力。
想接一家"专有签名"的云，查完文档发现根本不用写签名器
本来打算按老办法给金山云 KS3 写一套独立的 HMAC-SHA1 签名器，但官方文档给出的签名示例始终凑不出一个能验证的完整数值向量——没有向量就没法离线证明签名对不对，这是团队定下的硬规矩，不能跳过。查证过程中发现优刻得 US3 反而只支持标准 SigV4，可以直接复用现成的 s3-core，于是临时换了目标。
这次没有明确答案：一个没法在合并前验证的猜测
又拍云比想象的复杂：原生 REST API 有官方给出的完整签名向量，但没有"列出我的所有存储桶"这个接口；切到 S3 兼容模式能列桶，但签名要用的 region 字符串官方文档没写。两条路各自缺一块拼图，最后选了能列桶的那条，把缺的那块拼图明确标成"未经证实"，而不是假装它完整。
接入第八家云,真正的工作量在查文档,不在写代码
Backblaze B2 是目前接入最省事的一家云——endpoint 格式和 AWS 一样,现有代码不用改一行就能解析对。但"省事"仅限于写代码这一步：真正花时间的是逐项核实它的标签、ACL、版本控制到底支不支持，而不是把 R2 或 MinIO 的能力位抄一份改个名字。
第三家"S3 兼容"的云，第一次连 endpoint 都不按套路来
B2 和 Wasabi 的 endpoint 都是 s3.{region}.xxx.com 这个形状，现成的 region 解析代码直接就能用。DigitalOcean Spaces 打破了这个巧合——endpoint 不带 s3. 前缀，得照抄 R2/MinIO 那套"专用构造函数"的老办法。但这次也有个意外的好消息：它的对象 ACL 限制恰好和 Nebula 现有实现完全对齐。