腾讯云：都是你自己的错，我哪里有错
这两天测试了用 AWS-S3-SDK 访问了腾讯云“对象存储”，腾讯云官方明确说是兼容的，并且给出了参考代码。 但是我拿到手一跑就发现，压根没法用。所以我反手就立刻在帮助文档上划线并评论了一句：“实测没法用”，并附上了错误报告。 很快啊，就被转成了工单，被第一个人工客服（确定）开始处理。这之间仅间隔了 56 秒，对于帮助文档的评论来说，这处理速度可以说是神速了，非常值得称赞👍。
但是，没聊上两句，我就感觉有点被骑在头上了。因为我的测试代码完全是复制、粘贴他们的，只是把 Access Key ID / Access Key Secret 改成了我自己的。从报错信息看起来与此完全无关，但他们一上来就说我传参有问题，我就觉得：我要开始在这上面浪费时间帮他们找问题了。
事情已经过去了，我的问题已经解决，然而他们的文档还没有改。这里简单摘录一下聊天记录💬：
2025-04-23 09:55:19 用户:
不知道这段代码是不是还能用，我实测不行。
sync.go:53: operation error S3: PutObject, resolve auth scheme: resolve endpoint: endpoint rule error, Invalid region: region was not a valid DNS name.
我的简单得多， 但是200字符限制了，不能贴。
腾讯云工程师 2025-04-23 10:07:54
您好，您这边提供下您那边代码完整的入参这边看下，根据您提供的信息来看是参数那边有问题的
然后我就花时间完整地写了一个最小可运行的测试用例，清晰地注明了哪些代码是他们的、哪些是我的、他们的代码错在哪一行：
2025-04-23 10:36:07
添加到附件了，你们自己跑跑看。
压缩完了才知道，.tar.gz 这么标准的文件都不支持是吧。
附件: xxx.zip
会不会是和我类似的结果：
$ go run main.go 2025/04/23 10:42:30 yours: operation error S3: PutObject, resolve auth scheme: resolve endpoint: endpoint rule error, Invalid region: region was not a valid DNS name. 2025/04/23 10:42:31 etag mismatch: "202cb962ac59075b964b07152d234b70" "d41d8cd98f00b204e9800998ecf8427e" panic: etag mismatch: "202cb962ac59075b964b07152d234b70" "d41d8cd98f00b204e9800998ecf8427e" goroutine 1 [running]: log.Panicln({0x140002abec8?, 0x22?, 0x140002abef8?}) /opt/homebrew/Cellar/go/1.24.1/libexec/src/log/log.go:446 +0x60 main.main() /Users/tao/Downloads/oss-test/main.go:70 +0x64c exit status 2
客服立马又来一句：
腾讯云工程师 2025-04-23 10:59:03
您好，您的这个问题目前确实是您那边入参导致的，还是建议您提供下完整的入参这边看下的
可是我™️除了访问密钥之外已经提供了所有的东西啊，怎么像个机器人一样：
2025-04-23 11:08:30
还有啥入参？不就是 key id 和 key secret 以及 （一个广州的） bucket 吗？我不能、也不应该把我的线上环境给你们测试吧。。。
不知道为什么，他们开始要打电话了：
腾讯云工程师 2025-04-23 11:27:23
您好，您这边方便电话吗
然而，电话里面仍然只复述了一件事：“你应该把你的密钥给我！”，我™️黑人问号❓
2025-04-23 11:43:49
就只有这些，随便找个你们的测试环境应该就能复现。 第一段代码几乎完全是你们的，跑不通。第二段是我自己的，用 http，成功。第三段是我自己用，但是用 https，失败。
客服不知道又吃了什么药，又开始复述了：
腾讯云工程师 2025-04-23 11:44:02
您好，如电话沟通这边需要您提供下完整的参数这边进一步核查的
至此，我暂时决定不予理会了，浪费时间。
然后，过了一阵，看起来是换人了，应该是个开发。总共回了 5 条消息后我才回复：
腾讯云工程师 2025-04-23 12:04:48
您好，已经收到您的问题，为更好的处理问题，我先确认下之前沟通的背景记录，预计30分钟左右反馈，有进展第一时间同步，感谢理解
腾讯云工程师 2025-04-23 14:40:56
您好，目前核实需要您参考这个代码，在LoadDefaultConfig添加config.WithRegion("ap-xxxx")，region按您实际所在桶地域配置，关于文档我们会后续优化，感谢理解
至此，问题勉强解决。但是我的测试中有两个问题，他们直接忽略，害我主动再问一遍：
2025-04-23 16:44:44
会解决 https 协议的请求 etag 计算错误/实质文件内容也错误 的问题吗？还是说只能 http。
然后，我感觉这个开发也开始宕机了：
腾讯云工程师 2025-04-23 17:43:30
您好，上述代码示例是解决这个报错的（ operation error S3: PutObject, resolve auth scheme: resolve endpoint: endpoint rule error, Invalid region: region was not a valid DNS name.），具体您可以参考如下完整的代码示例，我们测试可以https上传请求是正常
正常个铲铲，测试代码早就发给你们了（日志显示etag不匹配），用点心好吗。
2025-04-23 17:50:37
你的代码我跑过了，确实可以上传。但是你试一下再下载回来，发现文件不是同一个文件。
离谱吧，文件上传成功，关键是我还在上传的时候提供了 Content-MD5，这都能……算成功？
腾讯云工程师 2025-04-23 17:52:52
您下载使用代码帮忙贴下，可以的话直接给一个文本文件，我们分析一下看看具体报错
我又假装有耐心，又重新写了一个测试用例：
2025-04-23 20:28:15
再 GetObject 一下就好了啦，偷懒。
$ go run main.go SDK 2025/04/23 20:26:57 WARN Response has no supported checksum. Not validating response payload. 2025/04/23 20:26:57 上传的数据： 123 2025/04/23 20:26:57 返回的数据： 3 123 0 x-amz-checksum-crc32:iEhj0g==附件: xxx.txt
然后他们终于意识到我没有在找茬了：
腾讯云工程师 2025-04-23 21:41:11
您好，让您久等了，这里确认到，您的请求有携带x-amz-trailer: x-amz-checksum-crc32头部，但是COS目前不支持S3的trailer功能，您可在上传的时候关闭此头部，再尝试下载文件对比是否一致
直到这样，他们也没有告诉我怎么改。我怎么知道怎么去掉？用例不是你们写的吗？你们不是自己说的兼容吗？
2025-04-24 01:05:23
加上一句 config.WithRequestChecksumCalculation(aws.RequestChecksumCalculationWhenRequired) 看起来解决了。更新下文档吧，现在的代码完全没法用。
是吧？看起来是我自己的问题一样：
腾讯云工程师 2025-04-24 01:10:10
好的，感谢您的反馈，这边提交需求评估优化下
结案。
心累。在等待他们解决问题前，我已经使用别的方案了。当然，别家也声称兼容 S3，但是提供的测试代码也是完全不可用/跑不通的。我已经没有耐心免费为他们解决不属于我的问题了。
全世界真的是草台班子啊。什么时候把文档中的测试加入 CI/CD 啊？跑不通禁止发布更新。
无聊。
今日已被动结单，文档更新了吗？没有。