HTML5 Worker 实现API限流与重试的核心是将调度逻辑移至Worker，通过固定窗口计数、请求去重、并发控制实现限流；采用指数退避、环境检查、可中断机制实现可控重试；配合结构化消息通信、错误分类、资源清理与心跳兜底保障健壮性。
在 HTML5 中用 Worker 管理 API 请求限流与重试，核心是把请求调度逻辑从主线程剥离，由 Worker 独立控制频率、失败响应和恢复行为，避免阻塞 UI，同时保障请求不被浏览器或服务端误判为异常流量。
限流：在 Worker 内部做请求节拍控制
限流不是靠“等时间”，而是主动管理请求节奏。Worker 不应收到一个任务就立刻发请求，而要按预设规则排队、延迟、合并或丢弃。
- 用 固定窗口计数器（如每秒最多 3 次）：Worker 维护一个时间戳数组，每次请求前过滤掉 1 秒前的记录，超限时推迟到下一个窗口开始时再发
- 对同一接口做 请求去重 + 缓存复用：例如 /api/user/profile 在 30 秒内重复调用，直接返回上一次成功结果，不发新请求
- 结合 最大并发数限制（如最多并行 2 个 fetch）：Worker 维护 runningCount 变量，仅当
runningCount < max且队列非空时才发起下一轮，其余暂存待调度
重试：带退避、可中断、有状态的自动恢复
Worker 中的重试必须脱离“无限循环”模式，转为可控、可观测、可降级的策略。
- 失败后不立即重试，而是按 指数退避 延迟：第 1 次等 200ms，第 2 次等 600ms，第 3 次等 1800ms，超 3 次则停止并通知主线程
- 每次重试前检查环境：调用
navigator.onLine、判断是否页面可见（通过主线程传来的visibilityState）、确认内存未超阈值 - 支持外部指令中断：主线程发送
{ type: 'cancel-retry', id: 'order-123' }，Worker 查找对应任务并清除其定时器，不再触发后续重试
通信与状态同步：让限流和重试对业务可见
主线程需要知道当前限流是否触发、某次请求是否正在重试、失败原因是什么，这些不能只埋在 Worker 里。
立即学习“前端免费学习笔记（深入）”；
- 约定统一消息格式，例如：
{ type: 'rate-limited', endpoint: '/api/search', waitMs: 420 }或{ type: 'retrying', id: 'task-7', attempt: 2, nextAt: 1746734852345 } - Worker 主动上报关键指标：如
currentQps、pendingRetries、lastThrottleTime，主线程可据此动态调整业务逻辑（如禁用按钮、显示提示） - 错误分类透出：区分网络中断、HTTP 429、503、JSON 解析失败等，不同错误走不同降级路径（如 429 自动延长限流窗口，503 启动备用接口）
资源安全与生命周期兜底
限流和重试逻辑长期运行，必须防止内存泄漏、连接堆积或失效 Worker 持续占位。
- 页面卸载前，主线程发送
{ type: 'shutdown' }，Worker 清空所有定时器、abort 正在进行的 fetch，并在 500ms 内自行终止 - Worker 内部设置心跳超时：每 3 秒收一次主线程 ping，10 秒无响应则 self.close()，避免“僵尸线程”
- 所有 fetch 使用
AbortController，超时或取消时确保连接释放；避免未 catch 的 Promise 导致 unhandledrejection 积压
