重试不是“多试几次”，而是针对临时性故障的有边界策略：仅对网络错误、5xx（502/503/504）等可恢复错误触发；严格限制2～3次，避免加剧雪崩；采用带抖动的指数退避（如100ms→300ms→1s），并强制与幂等配合（复用Idempotency-Key），同时将超时作为重试前提而非附属，辅以全链路日志、动态开关和监控指标保障可观测性。
直接讲清逻辑链，别堆代码。面试官想听的是你对重试场景的理解深度，不是复制粘贴一个 retry 函数。
重试不是“多试几次”，而是有明确边界和策略
重试必须回答三个问题：什么时候重试、重试几次、每次等多久。不能只说“失败就 retry(3)”。要说明：
- 触发条件：仅对网络错误、502/503/504 等临时性错误重试；400/401/404 这类业务错误不重试
- 次数限制：通常 2～3 次足够，再多次大概率是服务不可用，继续重试只会加重负载
- 退避策略：第一次等 100ms，第二次等 300ms，第三次等 1s——用指数退避（exponential backoff），避免雪崩式请求
重试必须和幂等配合，否则就是埋雷
很多候选人只讲重试，漏掉最关键的一环：重试可能造成重复提交。比如下单接口被重试三次，用户扣款一次但生成了三笔订单。
Wjs Uploading Video
下载
将一个或多个视频上传至YouTube。当用户想“上传到YouTube”“发YouTube”“批量上传”“upload to YouTube”“post videos to YouTube”或发布到YouTube时使用此技能。
- 必须在请求头或参数中带幂等键（如 Idempotency-Key），服务端据此判断是否已处理过该请求
- 前端重试时不能重新生成幂等键，要复用首次请求的 key
- 服务端返回 409 Conflict 或 200 + 已存在标识时，应视为成功，不再继续重试
超时和重试是两件事，但必须串联理解
超时是客户端主动放弃等待；重试是在放弃后另起一次新请求。二者关系是因果链：
- 先设合理超时（如 8s）：比 P95 响应时间高 20%～30%，既防卡死又不过早放弃
- 超时后不立即重试：要区分是连接超时（request never sent）还是读取超时（response never arrived）
- 测试时不能靠“等慢接口”，而要用 mock 手段精准制造超时（如用 axios 的 adapter 返回 reject with timeout）
实际落地要考虑可维护性和可观测性
光能跑通不够，线上出问题得能快速定位：
- 每次重试日志打全：原始请求 ID、当前重试次数、错误类型、退避时长
- 提供开关能力：灰度期可关闭某接口重试，或动态调整最大次数
- 监控指标：重试成功率、平均重试次数、因重试挽回的成功请求数
