异步网络请求重试函数测试需验证重试行为、状态更新与取消逻辑：用 mock 控制响应模拟失败/成功，检查调用次数、延迟、指数退避、旧响应丢弃；断言 loading/isonline/errortext 等业务状态；验证 cancel 后定时器清除、fetch 停止及 aborterror 抛出。
测试带重试机制的异步网络请求函数，核心是验证它在失败时是否按预期重试、在成功时是否及时终止、在特定错误下是否主动放弃——而不是只看“有没有调用 fetch”。关键在于可控地模拟不同网络响应，并断言状态变化、调用次数和最终结果。
用 mock 拦截请求，精准控制每次响应
别依赖真实网络或代理工具。用 vi.mock（Vitest）或 jest.mock 替换 fetch 或 axios，让它返回你设计好的 Promise 行为：
- 第一次调用返回
Promise.reject(new DOMException('Failed to fetch', 'NetworkError'))，第二次返回成功响应，验证是否重试一次后拿到数据 - 连续三次拒绝，且错误类型一致（如都是
TypeError或DOMException），断言函数被调用了 3 次，最后抛出错误 - 对 401/403 等业务错误，mock 返回对应 status 的响应，验证是否调用
bail()或提前退出重试
验证重试逻辑本身是否健壮
光看请求发没发几次不够，要检查重试过程中的关键行为：
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
- 检查延迟是否生效：用
jest.useFakeTimers()控制时间，jest.advanceTimersByTime(1000)推进延迟，确认定时器被正确设置 - 验证指数退避：若配置了
minTimeout: 1000, factor: 2，第二次重试应等待约 2000ms，第三次约 4000ms，可用jest.getTimerCount()辅助判断 - 确保不重复 resolve：当第 2 次请求成功返回，而第 1 次的延迟还在跑，需通过 attemptId 或 signal 标识丢弃旧响应，避免状态错乱
覆盖真实中断引发的关键路径
用户感知的“失败”不是技术异常，而是功能表现。测试必须落到业务层：
- 网络失败时，是否更新了
isOnline = false？可用jest.spyOn监听 setter 或检查响应式状态 - 重试中是否显示 loading 状态、禁用按钮？断言相关字段（如
loading: true）是否在首次请求发出后置为 true - 最终失败时，是否调用
toast.error('请检查网络')？或设置了errorText字段且内容符合产品规范 - 有缓存 fallback 时，是否读取了
localStorage.getItem('cache-key')并返回？可预设 localStorage 值再触发失败流程
测试取消能力（如果支持 cancel）
带取消功能的重试任务，必须单独验证中断行为：
- 发起重试后立即调用
task.cancel()，断言后续重试未发生（如 fetch 调用次数为 1）、定时器被清除、Promise 被 reject 且 reason 是AbortError或自定义取消错误 - 在重试间隔中取消，确认不会触发下一次
setTimeout；可在setTimeout回调开头加if (isCancelled) return并验证其执行 - 若使用
AbortController，mock 的 fetch 需检查signal.aborted是否为 true，或在 reject 时抛出new DOMException('Aborted', 'AbortError')
