防抖和节流应用于重试触发源而非重试过程本身：用户点击用防抖（如500ms），自动轮询用节流（如3秒），且后端必须保障幂等性。
防抖和节流本身不是为“重试”设计的，而是为“高频触发”设计的。把它们用在请求重试上，关键在于分清场景：重试是失败后的补救动作，而防抖/节流是主动控制发起节奏。直接套用会逻辑错位——比如对一个已失败的请求反复防抖，反而可能掩盖真实错误、延迟恢复。真正有效的做法，是把防抖/节流用在“重试触发源”上，而非重试过程本身。
先明确：重试不该被防抖，但重试的“触发行为”可以
用户连续点击“重试按钮”，或网络不稳定时自动轮询重试，都会造成高频重试请求。这时问题不在重试逻辑，而在“谁在反复发起它”。防抖/节流应作用于这个发起入口：
- 对用户手动点击的重试按钮，用防抖（如 500ms）——防止手抖连点多次，只执行最后一次点击对应的重试
- 对自动轮询类重试（如每隔 2 秒检查状态），用节流（如最小间隔 3 秒）——避免因响应慢导致请求堆积
- 不建议对单个请求的内部重试链（如 Axios 的 retry config）加防抖，那会破坏重试时机判断
防抖型重试触发：适合用户主动操作
适用于“点击重试”“刷新列表”等由用户直接触发的场景。目标是忽略中间无效点击，只响应最终意图：
- 封装一个防抖后的重试函数：
const debouncedRetry = debounce(() => apiCall(), 500) - 绑定到按钮：
retryBtn.addEventListener('click', debouncedRetry) - 点击后若 500ms 内又点一次，前一次定时器被清除，只执行最后那次
节流型重试触发：适合自动轮询或状态监听
适用于“页面可见时轮询订单状态”“WebSocket 断线后指数退避重连”等持续性检查场景。目标是限制单位时间内的最大尝试次数：
- 用节流控制轮询频率：
const throttledPoll = throttle(checkOrderStatus, 3000) - 即使页面每秒触发 10 次 visibilitychange，实际最多每 3 秒调用一次
checkOrderStatus - 配合指数退避（如首次 1s，失败后 2s、4s、8s）效果更稳
别忘了：防抖/节流只是前端第一道过滤，不能替代服务端幂等
前端控制再严，仍可能被绕过（如抓包重放、脚本调用）。所以：
- 所有涉及写操作（提交、支付、创建）的重试，后端必须做幂等校验（如传入唯一 request_id）
- 前端可配合生成带时间戳+随机数的客户端 ID，随每次重试请求带上
- 对 400 类错误（参数非法）不重试；对 503/超时类错误才启用防抖/节流后的重试
