xueelf
[NOTE] 关于 Amesu 暂时停止维护的相关说明
由于各种因素，我在两个月前发起了 #1 相关投票，最终决定移除 QQ 频道的支持并将项目重构。在我重构完成后，QQ 机器人文档更新了关于 Web Hook 的相关说明（其实很早之前就支持了，但是文档一直都没更新），我便没有在第一时间发版，而是继续着手 Web Hook 的支持。
但在接触 Web Hook 的过程中，我遇到了以下问题：
- 对于 Web Hook 的参数没有任何说明，也没有提供测试数据，和小程序一样只告诉你参数不告诉你字段，全凭开发者自我探索。
- 文档中给出的 Sign 算法 Demo 只提供了 Go 语言版本，我为此特意去花了大量时间学习 Go，并阅读 Go SDK 源码来将其移植至 TypeScript。
- 在移植完成后代码并未按照预期执行，由于没有测试接口，debug 花费了大量的精力和时间，反复对照 Go 代码也并未找到问题所在。
- 在疑惑之中文档又更新了 Go 代码的示例，我直接运行了 Demo 贴出来的代码，发现连代码本身都是错的，输出不了预期内容，给出的示例参数和 Web Hook 实际返回的内容也不一致。
- 我又下载了 Python、Go、Node 等其它第三方 SDK 尝试 Web Hook 是否可以正常通过 Sign 校验，无一例外全部挂掉了，并且反馈无门。
总结，我很菜，本身也没有深入了解 Ed25519，将问题交给时间。
时间已经过去了一个月，在 @all-thoughts-are-broken 的协助下，我逐渐掌握到了问题的根本原因。
先说结论，我写的 Sign 算法没有任何错误。从头到尾，自始至终，都是 tx 的问题。
请求体内容错误
我们想要使用 Web Hook，就必须先要在 QQ 机器人开放平台 配置相关域名，将腾讯返回的签名进行校验，才能进行后续的操作。
然而，我从一开始就一直获取不到正确的签名内容。
正常来讲，在开发者平台输入相关 URL，点击确定后，腾讯会向目标地址发送一个 POST 请求，其中就包含了签名的相关数据，而其中的请求体应该是如下结构：
{"d":{"plain_token":"38bc73e16208135fb111c0c573a44eaa","event_ts":"1145141919"},"op":13}
但是我得到的却是这么一段东西：
{"d":{"plain_token":%REDACTED","event_ts":"1145141919"},"op":13}
如果是 "REDACTED" 也就算了，好歹是一个正常的字符串，但 %REDACTED" 是个什么鬼？拜它所赐，害得我 JSON 解析一直失败，花了大量的时间排错。
难道是代码有问题？在热心群友的帮助下，我将代码原封不动的发送过去提供测试，在查看日志时，我却发现对方的请求体一切正常。
根据 文档 中的描述，我们可以知道公钥是由 seed 生成的，而 seed 又是由 secret 计算得到的，那么问题极有可能出现在这里，于是我将 Bot 的 secret 给重置了。结果你们猜怎么着，新生成的 secret 长度与旧的完全不同（又是不知道什么时候暗改的，也同样的没有任何通告）。不出所料的，经过这么一番操作，我终于能正常获取数据了。
域名校验扑朔迷离
尽管签名数据的问题解决了，但我依旧无法正常添加服务地址。根据腾讯的限制，Web Hook 的地址栏只能填入域名，并且必须为 HTTPS 协议，也就是说，根本没有一个能快速本地调试的方案。
但好在我平时就有在使用 Cloudflare 与 Vercel，可以免去繁琐的步骤基于 Workers 或 Next.js 直接进行调试。更重要的是，它们可以自动为域名提供和更新 SSL 证书，而不必手动 3 个月更新（Apple：阿嚏）。
但不出意外的话，就要出意外了。不管我怎么操作，tx 一直提示我 URL 校验失败。
是代码写错了？因为官网并没有给出一个正确的示例数据，我无法判断是否是自己 Sign 算法是否正确。Cloudflare 和 Vercel 都只提供了 Node 的 runtime，tx 也没有给出除 Golang 以外的代码示例。于是我又花费了大量的时间，在本地基于同样的参数执行 Go 代码，最后却发现...计算出的 signature 结果，完全相同。🤡
难道是域名的问题？我的域名 yuki.sh 再怎么说也是在国外服务商注册的，而且 .sh 较为小众。于是...我又特意在腾讯云注册了一个新的 .com 域名，但...还是无法通过校验。也许是因为没有备案？我又花时间去提供了相关材料，完成了备案，但问题依然存在。🤡
就在这时，热心群友提出让自己也尝试一下，于是我将整个 Serve 代码打包发送过去供其测试，然后...域名添加成功。
Why？
『不能套 cf 的 dns 加速，我也是过不了校验，关了就好了，你套了没？』 「...」 『不过也奇怪，第一次校验失败，第二次就好了，可能是 Next.js 的问题』
都已经能正常收到 POST 请求了，为什么 DNS 流量加速会导致域名无法通过校验？尽管疑问重重，但都已经不重要了。受到这番话的影响，我直接在本地搭建了内网穿透，没有使用任何框架，用原生 Node 模块写了一个临时服务，便有了以下的场景：
（输入网址，按下确认） 校验失败 （观察本地日志，并没有收到任何请求）
（？） （刷新页面，输入网址，再次按下） 校验失败 （收到了请求，正常响应，但未通过）
（沉默、怀疑人生） （这时，脑子里突然回想起了那句“第一次校验失败，第二次就好了”）
（刷新页面，输入网址，狂点鼠标） （弹出二维码） （？） （扫码） 添加成功 （...）
So Tencent, Fuck You.