Appearance
超时、重试与幂等：接口治理中的失败恢复
主题边界
- 失败恢复的核心不是“统一重试三次”，而是判断故障是否瞬时、请求是否幂等、重试是否会放大系统压力或业务副作用。
- 超时、重试、退避和幂等必须一起设计，单独讨论其中一项往往没有意义。
机制与流程
- 超时用于限制等待成本，避免请求无限挂起；重试用于对抗瞬时故障，如抖动、短暂 5xx、连接中断。
- 指数退避和抖动用于避免失败时的同步风暴，减少客户端同时重试对服务端的进一步冲击。
- 幂等键、请求去重或资源版本控制，是保证重试不会重复创建副作用的关键。
关键差异
- 连接建立失败、网关超时、可重试 5xx 和业务校验失败，不应使用同一重试策略。
- 技术层可重试不等于业务层可重试；支付、下单、消息投递一类操作尤其依赖幂等设计。
边界条件
- 无脑前端重试会放大雪崩和重复副作用，在高峰期尤其危险。
- 超时值过短会把正常慢请求误判成失败，超时值过长则会拖垮用户体验和资源占用。
工程落点
- 接口 SDK、请求库和 BFF 层通常会集中实现超时、退避和错误分类，而不是让业务页面各自复制一套逻辑。
- 这道题很适合顺带讲服务降级、幂等键和可观测性埋点。