断点续传必须放弃原生表单直传，改用file api+fetch分片上传，并通过服务端状态校验实现可靠恢复；navigator.online不可靠，应以轻量探测请求配合abortcontroller判断网络；所有分片需携带幂等标识，前端不依赖localstorage进度。
网络闪断时，原生 <input type="file"> 提交必然失败且无法恢复——它不暴露任何上传控制权，也没有状态回传机制。必须放弃表单直传，改用 File API + fetch 手动分片管理，并在服务端配合校验。
为什么 navigator.onLine 不能用来判断闪断
navigator.onLine 在绝大多数闪断场景下仍返回 true：Wi-Fi 路由器假死、4G 基站切换间隙、DNS 解析卡顿、代理超时等，浏览器底层 TCP 连接已断，但该属性毫无感知。依赖它做重试判断，等于盲发请求。
- 真正可用的是轻量探测请求，例如：
fetch('/api/ping', { method: 'HEAD', signal: controller.signal }) -
AbortController必须设超时（建议 3–5s），否则 UI 卡住不动 - 探测地址必须同源、无后端逻辑（如
/favicon.ico或专用/health），避免引入额外失败点
上传中断后如何准确恢复到上一片
断点续传的核心不是“记住第几片”，而是“服务端确认哪几片已落盘”。前端 localStorage 存的进度极易失效：用户清缓存、换设备、多标签并发上传都会导致状态错乱。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 每次上传前先发请求查服务端状态：
GET /upload/status?fileId=xxx，返回{ uploadedChunks: [0,1,3] } - 前端跳过已传索引，从最小未传索引开始（如
2），而不是依赖本地计数器 -
file.slice(start, end)的end必须为file.size，不能写成start + shardSize（末尾越界） - 切片数量必须用
Math.ceil(file.size / shardSize)计算，否则最后一片被漏掉
重试策略必须带退避和上限，否则压垮服务端
网络闪断常伴随抖动，连续重试会触发大量重复请求，既浪费带宽，又可能被网关限流或服务端拒绝。
- 采用指数退避：起始延迟
1000ms，每次 ×1.6，上限硬设为30000ms - 单个分片最多重试
3次，超过即标记为失败，不再自动重试 - 每次重试前检查
document.hidden，页面在后台时暂缓重连，避免无效连接 - 重连成功后，不要立刻发剩余分片，等用户下一次点击或
visibilitychange回前台再继续
最易被忽略的一点是：所有分片上传必须携带幂等标识（如 fileId + chunkIndex），服务端据此去重。前端哪怕本地状态全丢，只要能重新计算出同一 fileId，就能从服务端拉取最新进度继续——这才是真正可靠的断点续传基础。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
