用免费模型写一个最小复现服务器

从结论说起：当客户端对接远程服务失败时，一个能帮你写一个小型复现服务器的免费模型，往往比读取堆栈跟踪并告诉你哪里出了问题的大型模型更有价值。堆栈跟踪是对某一次失败的压缩记录，而复现服务器则给这个失败一个稳定的地址，你可以反复访问、修改并从中学习。

你可以用任何不担心成本的模型端点以及任何能在分钟内部署的一次性服务器来运行这个流程；本文示例中用到的是 MonkeyCode 的免费模型访问和免费服务器选项。声明：本文是作为 MonkeyCode 产品推广的一部分撰写的。下面的代码不依赖该供应商，只依赖于生成一个小服务器并将其部署到可达位置的能力。

假设你维护一个小型的 API 客户端，已经正常工作了数月，但某天早上一个合作方开始返回 503，并在 Retry-After 头中提供了一个浮点数而不是整数。堆栈跟踪指向你代码中调用 int() 处理该头的那一行。读取堆栈跟踪的模型可以告诉你加一个守卫来保护这个转换，这个答案可能正确，但它无法证明你的整个重试逻辑没有问题。如果你接受这个修复并继续往后走，后来可能会发现同一个服务还会发送 Retry-After: never，或者直接省略这个头，而你的代码会把这些情况当作零秒处理，持续猛击那个端点。

另一种做法是让模型创建一个复现服务器，给这个失败一个稳定的地址。你不问诊断结果，而是让模型生成一个小型 HTTP 服务器，返回你日志中看起来异常的状态码、响应头和响应体。然后你让实际的客户端对接这个服务器，而不是对接一个已经过去的错误。一旦你的客户端可以按需复现这个失败行为，调试就从猜谜变成了对比。

一个刻意的复现服务器可以做到这么小：

from http.server import BaseHTTPRequestHandler, HTTPServer

class Repro(BaseHTTPRequestHandler):
    def do_GET(self):
        self.send_response(503)
        self.send_header('Retry-After', '2.5')
        self.end_headers()
        self.wfile.write(b'try again later')

HTTPServer(('0.0.0.0', 8000), Repro).serve_forever()

这里面的价值不在于服务器的复杂程度，而在于响应头现在是可以控制的了。当你用这个七行服务器运行生产客户端时，你可以精确复现那个异常，然后每次只改变一个变量。把 2.5 改成 2、改成 0、改成字符串 never，或者直接删掉这个头，观察你的客户端哪些版本能处理，哪些版本会挂掉。

一个极简的客户端让失败变得具体：

import time
from urllib import request, error

for _ in range(2):
    try:
        request.urlopen('http://127.0.0.1:8000/')
    except error.HTTPError as e:
        time.sleep(int(e.headers['Retry-After']))

这组配对立即暴露了 bug：int('2.5') 在 time.sleep 被调用之前就抛出了 ValueError。这是一个浅层的例子，但这个工作流可以扩展到更有趣的失败场景：某个 JSON 字段有时是数组有时是对象、Content-Type 不匹配、响应体在客户端没有声明 gzip 的情况下却以 gzip 到达、或者重定向从 POST 变成了 GET。

免费模型的作用是帮助从嘈杂的证据中构建那个复现服务器。你粘贴相关的日志片段或载荷结构，让模型生成一个精确返回该异常的小型服务器。然后在部署之前你可以逐行阅读生成的代码；因为服务器很小，审查很快，而且它是隔离的，一个错误不会碰到你的本地数据库或真实用户。如果生成的服务器没有复现出那个失败，这本身就是有用的信息：说明你对请求的 mental model 是不完整的。

部署到免费服务器会在一个有意义的方面改变测试。本地复现可能隐藏 DNS、代理超时或出站连接行为的差异。当复现服务器运行在你无法控制的服务器上时，你的客户端必须穿越真实的网络边界而不是访问 localhost。这就把超时和重试从假设性的顾虑变成了可观测的数字。你可能会发现，在本地循环中看起来很慷慨的重试延迟，在一个免费服务器将连接保持两秒后才响应的环境下消失不见了。

局限性与收益同样重要。免费模型可能产生一个看起来合理但编码的假设与日志中不同的复现器，所以你仍然需要将生成的代码与证据对比。免费服务器可能不会在请求之间保持状态，所以依赖 cookie、session 或缓存身份验证的失败如果不额外处理将很难复现。你的机器和免费服务器之间的网络延迟会模糊超时边界的边缘，免费层也可能会限制持续的突发请求。不要向第三方模型或服务器发送客户数据、凭据或生产秘钥；一个脱敏后的结构几乎总是足够的。

这种方法并非适用于所有失败。如果你已经有了一个对接真实服务的 staging 环境，或者可以安全地在生产环境添加临时日志，复现服务器通常是不必要的。它也不能替代修复客户端的解析和重试策略；复现器只是让 bug 变得可重复，并不能让设计变得正确。而且如果失败涉及有状态握手、数据库或会改变数据的下游服务，你通常最好使用 fixture 在本地复现，而不是部署一个假服务器希望它表现得足够像真实服务。

下次当一个客户端失败伴随着模糊的堆栈跟踪到来时，试着让一个免费模型写一个能引起相同症状的最小服务器，然后把你的代码跑在上面，改变一个变量。你可能会发现诊断其实不在堆栈跟踪里，而是在你的客户端和你终于变成实物的失败之间的那个循环里。