我有一段代码，带着22个全部通过的测试，还有两位独立评审看过。没有任何一方提出异议。然后我把它指向一个别人拥有的真实API，第一次实时读取就崩了。

不匹配的地方一句话就能说清：我的解析器要求ISO 8601格式，而文档里写的API返回的是Unix秒。修复不是一行代码的事。它牵动了五个文件、74行解析器和52行测试。那个假设很小；让它变得安全却一点都不小。

打开网易新闻 查看精彩图片

为什么什么都没拦住它

我的测试用ISO，是因为我的代码用ISO，所以它们彼此一致，却从来没去核对现实。测试夹具是写解析器的那个人写的，它们编码了同一个假设。整套测试确认了内部行为，却从没挑战过ISO这个前提，因为这两半都来自同一个脑袋。内部一致不等于正确，而那一套测试根本分不出差别。

两位独立评审也漏掉了。我无法证明原因，也不打算编一个理由。我能展示的是：解析器和每一个夹具都编码了同一个ISO假设，所以摆在任何人面前的所有产物里，都没有提供那个与它相矛盾的真实契约。

真实系统逼出了重定向问题

对着真实系统工作时，重定向的边界控制变得重要，于是来了一位独立的破坏者。在Python 3.13里，默认的重定向处理器会从req.headers重建被重定向的请求，只丢掉内容长度和类型。我的X-API-Key就坐在那个头部集合里，所以被重定向的请求继承了它。Python有Request.add_unredirected_header()专门处理这个，它会把某个头部标记为不会添加到重定向请求中。我当时没用它。破坏者用一个哨兵值和一个跨源的Location离线复现了问题，哨兵确实跨过去了。

没有任何实时FIPSign凭证被证明跨过了源。缺陷是真实的，而且没有发布。我不是靠审计自己的代码发现的，也不是我自己发现的——是真实集成让这个问题值得被问出来，而一个不属于我的位置回答了它。

十周协作与一个意外阻断

2026年6月7日，我在tacoda/keystone这个代理章程框架上开了一个issue，问能不能针对真实签名API做一个窄适配器测试。FIPSign（mobydickfinance）说可以，然后做了一件我没想到的事：他交出了可弃用的API密钥，按需轮换，并在那个线程里待了十周。

这次协作产生了一个我无法解释的阻断。POST /mandate返回了一个Cloudflare 1010，browser_signature_banned。这让签发环节的循环停了下来：没有创建mandate，CAPTURE、PATCH和EVALUATE都没有运行。

我本可以去猜。他没让我们任何一个人这么做。他的回复是：

直接核对了两个问题，而不是从假设出发。

然后他列出了自己实际做的事。审查了Worker源码里的CORS和源处理，确认通过API密钥认证的服务器到服务器调用根本不会进入那段逻辑。专门检查了Bot Fight Mode。