断网重连时恢复异步任务的关键是主动保存执行上下文并显式控制生命周期；需在原子任务间隙记录索引或ID、持久化结果、幂等处理、网络探测后启动续执行，并精准区分网络错误与业务错误。

断网重连时恢复中断的异步任务，关键不是“自动续跑”，而是主动保存执行上下文 + 显式控制任务生命周期。JavaScript 本身没有运行时挂起/恢复机制，必须靠代码设计实现“可中断、可续传”的语义。

明确任务中断点：只在原子任务间隙暂停

每个异步任务本身不可中断（如一个 fetch 或上传 chunk），但多个任务之间可以停顿。因此恢复的前提是：记录当前执行到第几个任务、哪些已成功、哪些待执行。

• 用索引（i）或唯一 ID 标记任务序列位置，而非依赖时间戳或状态字符串
• 每次任务完成，立刻持久化结果（如 localStorage 或内存缓存），避免重连后重复执行
• 示例中 processTacks 的 result.push(...) 就是天然的进度快照点

网络恢复后触发续执行，而非监听“重连成功”事件

不要等 WebSocket 的 open 或 online 事件才启动恢复——它们可能早于业务就绪。更可靠的做法是：由业务逻辑主动判断是否可继续。

java-api-doc-generator

分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。

下载

• 在 start() 内部加一层网络探测（如轻量 fetch('/health')），成功后再推进后续任务
• 将重试与恢复解耦：断网时调用 pause()；重连后调用 start()，函数内部自动从断点继续
• 避免在 online 事件里直接调用 start()，防止多次触发或竞态

任务结果需幂等，支持重复提交或跳过

恢复过程中，无法 100% 确保某次任务是否真正失败还是只是没收到响应。因此每个任务应具备幂等性：

• 服务端配合：接口支持 idempotency key（如请求头 X-Idempotency-Key）
• 客户端兜底：对已记录成功的任务，直接跳过；对状态未知的任务，先查服务端确认再决定重试或忽略
• 例如上传大文件时，用分片 hash 校验 + 服务端已存在分片列表，避免重复上传

错误类型要区分，避免把 401 当作网络问题重试

断网重连场景下，常见错误包括 TypeError: Failed to fetch、NetworkError、AbortError，而 401 Unauthorized 或 404 Not Found 属于业务错误，不应纳入恢复流程。

• 在 catch 中用 err.name === 'TypeError' && !err.message.includes('status') 初筛网络类错误
• 对非网络错误，立即 reject 并终止整个任务流，交由上层统一提示（如登录过期需跳转）
• 恢复前可加一次 token 刷新，确保认证有效，再继续后续任务

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南