下游 5xx 就重试？聊聊 SRE 最容易想当然的「默认重试」假设与幂等边界

【背景】 最近主持复盘一起 P2：订单服务调支付网关偶发 5xx，框架默认开了「失败重试 3 次」，看起来是无害的兜底。结果支付侧当晚收到了约 4 倍的重复请求，风控直接把我们拉黑 30 分钟，业务全链路瘫痪。事后一查：支付网关对部分 5xx（其实是「处理中，结果未定」）返回了 503，而我们的重试逻辑只认 HTTP 状态码、不认响应体里的业务状态。这一条事故让我意识到——「下游 5xx 就重试」是 SRE 圈子里最容易想当然的一个默认假设，它成立的前提是「5xx = 请求根本没被执行」，但现实中大量网关/中间件/第三方 API 的 5xx 恰恰是「执行了但没告诉你结果」。

【常见分歧与几种做法】 我观察下来，团队里对「该不该默认重试」大致分成三派：

1. 全量重试派：认为 5xx 就是失败，重试是标配，简单直接。典型配置是 retries=3, backoff=exponential，几乎所有 HTTP 客户端都这么写。
2. 全量不重试派：认为重试本身就是风险源，宁可让调用方自己决定。典型做法是框架层关掉默认重试，由业务代码显式写 retry。
3. 按幂等性分级派：把接口分成「读/幂等写/非幂等写」三档，只对前两档开默认重试，非幂等写必须显式声明 retryable=true 并附带幂等键。

每一派都有真实事故背书，也都有对应的「反例」。我见过全量重试派把第三方短信 API 打到限流；也见过全量不重试派让一次瞬时抖动直接变成用户可见的 500；更见过按幂等性分级派把「幂等键」做成一个字符串，结果两边时间戳不一致，幂等直接失效。

【我的倾向与理由】 我倾向第三派，但有几个补充：

• 5xx 不等于「没执行」，这是第一性原理。重试前必须能证明「幂等」，不是「我觉得这个接口应该幂等」。
• 重试的触发条件不能只看状态码。HTTP 5xx 里，502/503/504 的语义是「网关/上游没处理完」，500 的语义是「处理了但出错了」——这两类在重试策略上应该分开。
• 重试必须和限流、熔断、退避绑在一起，单独的重试就是流量放大器。
• 幂等键的生成方必须是调用方，且要在请求头里显式传递，不能依赖服务端自己拼。

【想听大家聊聊】

• 你们团队对「默认重试」的立场是哪种？有没有被默认重试坑过、或者被「不敢重试」坑过的真实案例？
• 你们怎么定义「幂等」？是接口级别的，还是请求级别的？幂等键怎么生成、怎么传递、怎么校验？
• 对「500 和 503 要不要分开重试」这件事，你们有没有可落地的判断标准，还是只凭经验？
• 第三方 API（短信、支付、风控）的重试策略，你们是怎么和对方对齐的？有没有被对方「重试不友好」坑过的？
• 框架层重试和业务层重试，你们是怎么划界的？谁拥有最终决策权？

欢迎贴具体场景和配置，越具体越好。这个话题我预期会吵，但我更喜欢吵出能落地的判断标准，而不是各喊各的口号。