调用外部服务的错误处理怎么写：重试、超时、熔断与降级审查提示词
代码里要调用第三方接口、下游微服务、数据库或消息队列时用：让 AI 检查超时有没有设、哪些错误能重试、重试会不会造成重复操作、下游挂了怎么降级，并给出改好的代码。
通用大模型 对话模型通用
请以「下游随时可能变慢、报错或完全不可用」为前提，审查下面这段调用外部依赖的代码。 背景： - 语言与使用的客户端库：[如 Go + net/http] - 被调用的依赖：[如短信服务商接口、订单服务] - 这个调用所在的场景：[如用户下单的同步请求、后台定时任务] - 调用是否有副作用：[只读查询/会扣款或发消息] - 下游的超时或限流说明：[文档写的限制，没有就写未知] - 代码： [粘贴代码] 检查清单： 1. 超时：连接超时和读取超时是否都设置了；整体耗时有没有上限；同步请求场景下，所有重试加起来会不会超过上游给我们的时间。 2. 错误分类：哪些错误可以重试（网络抖动、超时、明确的 503 / 429），哪些绝对不能重试（参数错误、鉴权失败、业务拒绝）；代码是否区分了。 3. 重试策略：次数上限、指数退避加随机抖动、是否遵守 429 返回的 Retry-After。 4. 幂等：有副作用的调用重试前，是否有幂等键或去重手段，避免重复扣款、重复发短信。 5. 保护措施：下游持续失败时是否需要熔断；有没有降级方案（返回缓存、默认值、排队稍后处理）以及降级时如何告知用户。 6. 可观测性：失败时日志是否包含足够定位的信息（下游名称、耗时、状态码、请求 ID），且不打印密钥和个人信息；是否有失败次数指标。 7. 资源：响应体是否关闭、连接是否复用、并发调用是否有上限。 输出： - 问题表：问题 | 风险场景 | 建议； - 改写后的完整代码，用这个语言常用的方式实现（可以使用成熟的库，说明库名）； - 一张「错误类型 → 处理方式」的对照表，方便团队以后复用。
高亮处换成你自己的内容：[如 Go + net/http]、[如短信服务商接口、订单服务]、[如用户下单的同步请求、后台定时任务]、[只读查询/会扣款或发消息]、[文档写的限制，没有就写未知]、[粘贴代码]
ChatGPT Plus 充值
已被复制 0 次
使用说明
怎么填变量：[调用是否有副作用] 决定了重试策略的上限——只读查询可以放心重试，扣款、发短信、创建订单这类调用没有幂等保护时，一次重试就可能造成真实损失。[这个调用所在的场景] 用来判断能等多久，用户同步请求一般只能等几秒，后台任务可以慢慢重试。
常见坑：
- 很多 HTTP 客户端默认没有超时或超时极长，下游一卡住，线程或连接就被占满，最后整个服务不可用。
- 对所有错误统一重试，会把「参数错误」重试三遍，或者在下游已经过载时继续加压。重试要加退避和抖动。
- 多层调用每层都重试 3 次，最底层实际会被调用 27 次。重试最好只放在一层。
追问技巧：追问「模拟下游超时、返回 500、返回 429、连接被拒绝四种情况，分别说明这段代码会怎样表现」，再让它写成测试用例。
示例输出
示例，仅供参考（错误类型对照表节选）
| 错误类型 | 例子 | 处理方式 |
|---|---|---|
| 网络抖动 / 超时 | 连接重置、读超时 | 退避重试，最多 2 次；有副作用时必须带幂等键 |
| 限流 | HTTP 429 | 按 Retry-After 等待；超过整体时限则降级 |
| 下游故障 | HTTP 503 | 重试 1 次，连续失败触发熔断 30 秒 |
| 请求本身有误 | HTTP 400 / 401 / 403 | 不重试，记录日志并告警 |
| 业务拒绝 | 余额不足 | 不重试，原样返回给上游 |
go
client := &http.Client{Timeout: 3 * time.Second} // 整体超时，含连接与读取
req.Header.Set("Idempotency-Key", orderID) // 重试时保持同一个键同款作品
用这条提示词做出来的作品；原作者会因此获得积分
还没有同款，来做第一个。
0 条评论
还没有评论，来抢沙发～