三步稳住大文件上传：分片上传（切2–5mb小块并行上传）、文件哈希实现秒传与校验、断点续传（查服务端已传分片索引后补传）。全程支持进度感知、失败重试与暂停续传。
直接切片、记录进度、服务端配合，三步就能稳住大文件上传。关键不在“能不能传”，而在“断了能不能接着传”和“重复文件要不要重传”。
分片上传：把大文件切成可控的小块
单次上传几GB文件容易超时或被服务器拦截，分片就是把文件按固定大小（比如 2–5MB）切成多个 Blob 片段，逐个发请求。这样每个请求轻量、可并行、失败只重传单片。
- 用 File.slice() 按偏移量切割，避免一次性读入内存
- 每片带上序号（index）、起止位置、所属文件哈希，方便服务端识别和排序
- 推荐分片大小设为 2MB 或 5MB：太小会增加 HTTP 请求压力，太大削弱分片意义
文件唯一标识：靠哈希实现秒传与校验
秒传不是魔法，是靠文件内容的唯一指纹。上传前先算整个文件的 MD5（用 spark-md5 增量计算，防卡顿），发给后端查询——如果该哈希已存在，直接跳过上传，返回成功。
- MD5 计算必须在前端完成，且不能用
FileReader.readAsText()全量读取，要用 ArrayBuffer 分块累加 - 服务端需持久化存储「文件哈希 → 最终文件路径」映射，供秒传判断
- 合并完成后，服务端可用同一哈希值校验合并结果是否完整，防止传输损坏
断点续传：上传前先问“哪些片你已经有了？”
用户关掉页面、网络中断、刷新页面都不怕，只要重新进入，组件就查服务端：“这个文件哈希，目前已传了哪几片？”拿到已传索引列表，只上传缺失部分。
- 前端可在 localStorage 缓存当前文件的已传分片索引，作为兜底（但以服务端为准）
- 服务端接口需提供
/upload/check?fileHash=xxx，返回已上传的 chunkIndex 数组 - 上传逻辑要跳过已存在的 index，再按顺序发起剩余请求，最后统一触发合并
进度与体验：让每一步都可感知
原生 <input type="file"> 只能监听整体 load，分片后可以做到：每个分片有独立进度、整体进度 = 已传字节数 / 总字节数、失败分片支持单独重试。
- 用 XMLHttpRequest.upload.onprogress 或 fetch + ReadableStream 获取单片上传进度
- 整体进度建议用「已成功上传的字节数」计算，比单纯按分片数更准确（尤其末片不满额）
- 加上暂停/继续按钮、失败重试入口、取消上传清空临时记录，体验就完整了
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
