能实现大文件本地分片上传，关键在于稳定切片（5mb为优）、可控并发（4～6路）、服务端驱动断点续传、前端预计算md5防重复。
直接用 HTML5 File API 实现大文件本地分片上传，核心不在“能不能”，而在“怎么切得稳、传得准、断了能续、重复不白干”。关键不是堆代码，而是把切片逻辑、状态管理、并发控制和校验机制串成一条可靠链路。
一、合理切片：从 file.slice() 到 chunkSize 控制
切片不是越小越好，也不是越大越省事。5MB 是目前兼顾浏览器兼容性、服务端接收阈值（如 Nginx 默认 client_max_body_size=1MB）、网络波动容错性的常见起点。
- 用 file.slice(start, end) 获取 Blob 切片，注意它返回的是新 Blob，不读取内存，零拷贝
- 起始位置按字节偏移计算，避免用
chunkIndex * chunkSize累加导致浮点误差，改用Math.min(current + chunkSize, file.size) - 每个切片附带必要元信息：文件名、总片数、当前序号、唯一标识符（如基于文件名+大小+最后修改时间生成的 hash，非全量 MD5，避免首切就卡住）
二、上传调度：并发可控 + 进度可溯
一次发 10 个切片看似快，但容易触发浏览器连接池限制（Chrome 默认 6 个同域并发），也可能压垮后端上传接口。4～6 路并发是更稳妥的选择。
- 用 Promise 队列或 async/await 控制上传节奏，例如维护一个长度为 4 的运行中任务数组，空位出现即推新切片
- 每个 XMLHttpRequest 或 fetch 请求必须绑定 onprogress，监听
event.loaded / event.total，聚合后更新整体进度（不是简单平均） - 上传失败时保留错误切片索引，不中断整个流程，继续上传其余切片；后续重试只针对失败项
三、断点续传：靠服务端状态驱动前端决策
断点续传的前提是服务端能回答：“这个文件，你上次传到第几片了？” 前端不能自己猜，也不能只靠 localStorage 记录。
- 上传前先发一个轻量请求（如
GET /upload/status?identifier=xxx），获取已成功接收的切片列表 - 前端比对本地切片序号与服务端返回结果，跳过已传成功的，从第一个缺失序号开始上传
- localStorage 或 IndexedDB 存储仅作辅助（如页面刷新后恢复 UI 进度），主权威来源永远是服务端响应
四、防重复上传：MD5 校验放在切片前，而非上传后
秒传体验的关键，在于用户点击上传按钮后 200ms 内就知道“这文件我传过了”，而不是等所有切片跑完才判断。
- 用 SparkMD5 或 Web Crypto API 在前端快速计算文件哈希（推荐取前 1MB + 后 1MB 拼接计算，兼顾速度与唯一性）
- 上传前先 POST
/upload/check?md5=xxx，服务端查库确认是否已有完整文件 - 若命中，直接跳过全部切片上传，走秒传回调流程；未命中再进入标准分片流程
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
