JavaScript无原生断点续传能力，需手动分片、缓存状态、查询服务端已传分片并只传缺失部分；常见错误源于前端未持久化进度、服务端缺校验接口或分片校验不一致。
JavaScript 本身不直接处理文件上传中断的“断点报错”，因为浏览器环境没有原生的断点续传能力，也没有内置的上传状态持久化机制。所谓“断点报错”，通常是开发者在实现分片上传 + 断点续传逻辑时，因服务端未正确返回已上传分片信息、客户端缓存丢失、网络异常未捕获，或重试逻辑缺陷，导致续传时校验失败而抛出的错误（比如 409 冲突、412 预处理失败、或 JS 层面的 RangeError / TypeError）。
明确断点续传不是浏览器默认行为
浏览器的 XMLHttpRequest 或 fetch 发起上传请求时，一旦连接中断，整个请求就失败——不会自动记住传到第几个字节。要支持断点，必须由你主动把文件切片、记录已传分片、上传前先向服务端查询已存在哪些分片，再只传缺失部分。
常见错误场景包括：
- 前端没保存已上传分片的 hash 或索引，刷新页面后无法恢复进度
- 服务端未提供
/upload/check接口供查询已接收分片 - 分片校验方式不一致（比如前端用
File.slice()取 chunk，服务端用 MD5 计算整块但未对齐字节边界） - 重试时未清除失败分片的本地标记，导致跳过重传或重复提交
关键：用唯一标识管理分片状态
每个分片应有稳定 ID（推荐用文件唯一标识 + 分片序号 + 分片大小组合生成），并本地缓存其上传状态（如 localStorage 或 IndexedDB）。上传前先查服务端，再决定是否跳过或重传。
立即学习“Java免费学习笔记（深入）”；
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
示例逻辑片段：
// 假设 file.id 是通过 file.name + file.size + lastModified 生成的稳定 hash
const chunkId = `${file.id}_${index}_${chunkSize}`;
const cacheKey = `upload_${chunkId}`;
// 检查是否已成功上传该分片
if (localStorage.getItem(cacheKey) === 'success') {
return Promise.resolve('skipped');
}
// 否则发起上传，并在成功后标记
return uploadChunk(chunk, index)
.then(() => {
localStorage.setItem(cacheKey, 'success');
});
服务端必须配合提供分片查询与合并能力
前端再完善，若服务端不支持以下任一能力，断点续传就不可靠：
-
分片查询接口：如
GET /api/upload/chunks?file_id=xxx，返回已接收的分片序号列表 - 幂等上传：同一分片重复上传不应出错（HTTP 200 或 204），也不应破坏已有数据
- 合并校验：最终合并时验证所有分片完整性（如比对总 MD5、分片数量、大小总和）
如果服务端返回 409（Conflict）说“该分片已存在”，前端不要报错，而应视为成功并继续下一分片；若返回 412（Precondition Failed），说明校验不通过，需清空该分片缓存并重传。
网络异常时优雅降级与用户提示
上传中断本身不会抛“断点报错”，但你在恢复逻辑里可能手动 throw 错误。建议统一处理策略：
- 所有上传请求包装
AbortController，支持手动取消 - 用
fetch().catch()或XMLHttpRequest.onerror捕获网络失败，延迟 1–3 秒后自动重试（最多 2 次） - 重试失败后，保存当前进度到持久化存储，提示用户“已暂停，可稍后继续”
- 避免在控制台打印模糊错误如 “upload failed”，而是输出具体分片 ID 和 HTTP 状态码，方便定位
